Seller Dashboard account approved
The Exception Assistant, which appears whenever a run-time exception occurs, shows the type of exception, troubleshooting tips, and corrective actions. The Exception Assistant can also be used to see the details of an exception object.
An exception is an object that inherits from the Exception class. An exception is thrown by code when a problem occurs, and it is passed up the stack until the application handles it or the program fails.
|The options available in dialog boxes, and the names and locations of menu commands you see, might differ from what is described in Help, depending on your active settings or edition. This Help page was written with General Development Settings in mind. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Customizing Development Settings.|
The following table lists and describes an exception object’s properties. Depending on the type of exception, not all may appear.
|Data||An IDictionary object that contains user-defined key/value pairs. The default is an empty collection.|
|FileName||Name of the file causing the exception.|
|FusionLog||Log file that describes why an assembly load failed.|
|HelpLink||Link to the help file associated with the exception.|
|HResult||Coded numerical value assigned to a specific exception.|
|InnerException||Exception instance that caused the current exception. It is sometimes useful to catch an exception thrown in a helper routine and throw a new exception more indicative of the error, thereby providing more information. In such cases, the InnerException property is set to the original exception.|
|Message||Message associated with the exception. This is displayed in the language specified by the CurrentUICulture property of the thread that throws the exception.|
|Source||Name of the application or object that caused the exception. If Source is not set, the name of the assembly where the exception originated is returned.|
|StackTrace||String representation of the method calls on the call stack at the time the current exception was thrown. The stack trace includes the source-file name and program line number if debugging information is available. StackTrace may not report as many method calls as expected, due to code transformations that occur during optimization. The stack trace is captured immediately before an exception is thrown.|
|TargetSite||Method that throws the current exception. If the method that throws the exception is not available and the stack trace is not a null reference (Nothing in Visual Basic), TargetSite obtains the method from the stack trace. If the stack trace is a null reference, TargetSite also returns a null reference.|
The Exception Assistant dialog box appears when a run-time exception is thrown. The Exception Assistant displays the type of exception, provides additional information and links to troubleshooting tips, provides a way to search for additional help online, and allows the user to perform certain actions, such as viewing details of the exception.
To see a topic dealing with troubleshooting the type of exception you have encountered, click one of the tip messages displayed in the Troubleshooting Tips pane.
To perform actions associated with the exception, click one of the actions displayed in the action pane.
For information about how to enable or disable the Exception Assistant, see General, Debugging, Options Dialog Box.
The ability to debug another process gives you extremely broad powers that you would not otherwise have, especially when debugging remotely. A malicious debugger could inflict widespread damage on the machine being debugged. Because of this, there are restrictions on who can do debugging. For more information, see Remote Debugging Permissions.
However, many developers do not realize that the security threat can also flow in the opposite direction. It is possible for malicious code in the debuggee process to jeopardize the security of the debugging machine: there are a number of security exploits that must be guarded against.
For more information, see Debugging Managed Code.
When using Windows Authentication mode, be aware that granting an untrusted user permission to connect to msvsmon is dangerous, because the user is granted all your permissions on the computer..
Do not debug an unknown process on a remote machine: there are potential exploits that might affect the machine running the debugger, or that might compromise msvsmon.exe, the Visual Studio Remote Debugging Monitor. If you absolutely must debug an unknown process, try debugging locally, and use a firewall to keep any potential threats localized.
For more information, see Remote Debugging in Visual Studio.