This topic applies to:
Pro, Premium, and Ultimate
Just-In-Time debugging launches Visual Studio automatically when an exception or crash occurs in an application running outside Visual Studio. This enables you to test your application when Visual Studio is not running and begin debugging with Visual Studio when a problem occurs.
Just-In-Time debugging does not work for managed code that is hosted in a native application, such as Visualizers. If you install the .NET Framework on Windows Server 2003 or on Windows 2000 SP3 (or later), Just-In-Time debugging will not work for a process running in a limited user account in a Terminal Services session until the computer has been rebooted.
When you install Visual Studio, Just-In-Time debugging is enabled by default. If you need to disable or reenable Just-In-Time debugging, see Enabling or disabling Just-In-Time Debugging.
When Just-In-Time debugging is enabled, you can test your application outside of Visual Studio. When a crash or exception occurs, you will see a dialog box appears with a message that looks something like this:
An unhandled exception ('System.TypeInitializationException') occurred in terrarium.exe
When this dialog box appears, you can begin debugging with the following procedure.
To begin Just-In-Time debugging when an error occurs
In the Just-In-Time Debugging dialog box, in the Possible Debuggers list, click New instance of Visual Studio 2010 or click an instance of Visual Studio 2010 that is already running.
To use Visual Studio automatically for all future crashes, click Set the currently selected debugger as the default.
If you want to choose what types of code you will be able to debug, click Manually choose the debugging engines. If you do not choose this option, Visual Studio automatically selects the appropriate debug engines for the type of code in your program.
If your application contains an assembly with untrusted code, a dialog box with a security warning appears. This dialog box enables you to decide whether or not to proceed with debugging. Before you continue with debugging, decide whether you trust the code. Did you write the code yourself? Do you trust the coder? If the application is running on a remote machine, do you recognize the name of the process? Even if the application is running locally, that does not necessarily mean it can be trusted. In Internet Explorer, for example, a malicious ActiveX control could be running. Consider the possibility of such malicious code running on your computer. If you decide that the code you are about to debug is trustworthy, click Debug. Otherwise, click Don't Debug.
You can enable or disable Just-In-Time debugging from the Options dialog box.
To enable or disable Just-In-Time debugging
On the Tools menu, click Options.
In the Options dialog box, select the Debugging folder.
In the Debugging folder, select the Just-In-Time page.
In the Enable Just-In-Time debugging of these types of code box, select or clear the relevant program types: Managed, Native, or Script.
To disable Just-In-Time debugging, once it has been enabled, you must be running with Administrator privileges. Enabling Just-In-Time debugging sets a registry key, and Administrator privileges are required to change that key.
By default, Windows Forms applications have a top-level exception handler that allows the program to continue to run if it can recover. As a result, you must perform the following additional steps to enable Just-In-Time debugging of a Windows Forms application.
To enable Just-In-Time debugging of a Windows Form
Set the jitDebugging value to true in the in the system.windows.form section of the machine.config or application.exe.config file:
<configuration> <system.windows.forms jitDebugging="true" /> </configuration>
In a C++ Windows Form application, you must also set DebuggableAttribute in a .config file or in your code. If you compile with /Zi and without /Og, the compiler sets this attribute for you. If you want to debug a non-optimized release build, however, you must set this yourself. You can do this by adding the following line to your the AssemblyInfo.cpp file of your application:
For more information, see DebuggableAttribute.
Just-In-Time debugging may still be enabled even if Visual Studio is no longer installed on your computer. When Visual Studio is not installed, you cannot disable Just-In-Time debugging from the Visual Studio Options dialog box. In that case, you can disable Just-In-Time debugging by editing the Windows registry.
To disable Just-In-Time debugging by editing the registry
In the Start menu, click Run.
In the Run dialog box, type regedit, then click OK.
In the Registry Editor window, locate and delete the follow registry keys:
If your computer is running a 64-bit operating system, delete the following registry keys also:
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
You might see the following error messages that are associated with Just-In-Time debugging.
An unhandled win32 exception occurred in <program>. Just-In-Time debugging this exception failed with the following error: The logged in user did not have access to debug the crashing application.
This message indicates that Just-In-Time debugging failed because you do not have proper access permissions. For information on the required permissions, see [Obsolete] Remote Debugging Permissions.
Unable to attach to the crashing process. The specified program is not a Windows or MS-DOS program.
This error occurs when you try to attach to a process running as another user under Windows 2000.
To work around this problem, start Visual Studio, open the Attach to Process dialog box from the Debug menu, and find the process you want to debug in the Available Processes list. If you do not know the name of the process, look at the Visual Studio Just-In-Time Debugger dialog and note the process ID. Select the process in the Available Processes list and click Attach. In the Visual Studio Just-In-Time Debugger dialog, click No to dismiss the dialog box.
Debugger could not be started because no user is logged on.
This error occurs when Just-In-Time debugging tries to start Visual Studio on a machine where there is no user logged onto the console. Because no user is logged on, there is no user session to display the Just-In-Time debugging dialog box.
To fix this problem, log onto the machine.
Class not registered.
This error indicates that the debugger tried to create a COM class that is not registered, probably due to an installation problem.
To fix this problem, use the setup disk to reinstall or repair your Visual Studio installation.