Seller Dashboard account approved
|
||||||
|
||||||
Category Archives: Exception Handling
The Exception Assistant in Visual Studio 2013
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.
 Note |
|---|
| 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.
| Property | Description |
|---|---|
| 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. |
To find out more about an exception object
- Click View Details in the Actions pane. A dialog box appears showing the properties of the exception.
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.
- Type of Exception
- Displays the type of exception thrown.
- Additional Information
- Displays additional information about the exception.
- Troubleshooting Tips
- Displays links to troubleshooting tips that may help you discover the source of the exception.
- Actions
- Lists actions that can be performed, such as seeing more information about the exception object.
- Get Help Online
- Allows you to search for additional help online.
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.
There is an implicit trust relationship between the code you are debugging, and the debugger. If you are willing to debug something, you should also be willing to run it. The bottom line is that you must be able to trust what you are debugging. If you cannot trust it, then you should not debug it, or you should debug it from a machine that you can afford to jeopardize, and in an isolated environment.In order to reduce the potential attack surface, debugging should be disabled on production machines. For the same reason, debugging should never be enabled indefinitely.Here are some general recommendations that apply to all managed debugging.- Be careful when attaching to an untrusted user’s process: when you do so, you assume that it is trustworthy. When you attempt to attach to an untrusted user’s process, a security warning dialog box confirmation will appear asking whether you want to attach to the process. “Trusted users” include you, and a set of standard users commonly defined on machines that have the .NET Framework installed, such as aspnet, localsystem, networkservice, and localservice. For more information, see Security Warning: Attaching to a process owned by an untrusted user can be dangerous. If the following information looks suspicious or you are unsure, do not attach to this process.
- Be careful when downloading a project off the Internet and loading it into Visual Studio. This is very risky to do even without debugging. When you do this, you are assuming that the project and the code that it contains are trustworthy.
For more information, see Debugging Managed Code.
Local debugging is generally safer than remote debugging. Remote debugging increases the total surface area that can be probed.The Visual Studio Remote Debugging Monitor (msvsmon.exe) is used in remote debugging, and there are several security recommendations for configuring it. The preferred way to configure the authentication mode is Windows Authentication, because No Authentication mode is insecure.
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.
It is safer to debug locally, but since you probably do not have Visual Studio installed on the web server, local debugging might not be practical. Generally, debugging Web services is done remotely, except during development, so the recommendations for remote debugging security also apply to Web services debugging. Here are some additional best practices. For more information, see Debugging XML Web Services.- Do not enable debugging on a Web server that has been compromised.
- Make sure you know the Web server is secure before debugging it. If you are not sure it is secure, do not debug it.
- Be especially careful if you are debugging a Web service that is exposed on the Internet.
Two Visual Studio tools that require thinking about security are the following:- Source Server, which provides you with versions of source code from a source code repository. It is useful when you do not have the current version of a program’s source code. Security Warning: Debugger Must Execute Untrusted Command.
- Symbol Server, which is used to supply the symbols needed to debug a crash during a system call.
See Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger
SharePoint Samurai 