Just-In-Time debugging is trickier on Windows Vista than on previous operating systems. Today I am going to talk about the various knobs that you can use to make this better.
- Enable Jit Debugging Windows 10
- How To Enable Jit Debugging On Windows Vista
- Fix Jit Debugging Windows 10
Hint #1: Use Visual Studio 2008 Beta2. I expect Beta2 to be out soon. If you are developing on Windows Vista, I definitely recommend trying Beta2 over previous versions of Visual Studio. While it is still a beta, Visual Studio 2008 greatly improves the Vista experience (at least for the debugger). As far as Just-In-Time debugging goes, the fact that you can't debug elevated processes was a big problem for Visual Studio 2005.
Hint #2: If you get a Windows Error reporting dialog for your application and there is no 'Debug' button, then click 'Send Report' and then you will get a second dialog with a debug button.
Hint #3: Windows Error reporting has several configuration settings. If you are finding that Windows Error Reporting is preventing you from debugging your applications, there are a few settings that you can tweak.
First, you can define the 'AeDebugAuto' string:
[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionAeDebug]
'Auto'='1'
Note that this is a String value, NOT a DWORD.
If this doesn't work, Error reporting can also be disabled at various levels through control panel:
- Start->Control Panel
- Click 'System and Maintenance'
- Click 'Problem Reports and Solutions'
- Click the 'Change Settings' link on the left side
- Click the 'Advanced settings' link
- Configure at will
Hope this helps.
[Updated on 5/23/2008] In Vista SP1 and Windows Server 2008, there is now a registry key to save the generated .dmp file: http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx
Hi ApostleRD,
1. What is the exact issue you are facing? Why do you want to enable it?
2. Are you receiving any error messages relating to JIT Debugging?
3. Have you made any recent software or hardware changes on the system?
Just-In-Time debugging is a feature that launches the Visual Studio debugger automatically when a program, running outside Visual Studio, encounters a fatal error. Just-In-Time debugging allows you to examine the error before the application is terminated by the operating system. The Visual Studio debugger does not need to be running when the error occurs.
For further information, refer the article:
Important: The above mentioned link contains steps to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs.
For more information, you may refer to the article:
I would suggest you to disable script debugging in Microsoft Internet Explorer and check for the issue.
a. Open Internet Explorer.
b. Click on Tools.
c. Click internet options and then advanced tab
d. Under browsing section>> uncheck 'disable script debugging (both others and Internet Explorer) ' and 'display a notificationabouteveryscripterror'.
The .jdinfo command uses a JIT_DEBUG_INFO structure as the source of the exception and context for just in time (JIT) debugging. The address to the structure is passed to the .jdinfo command using the %p parameter that is specified in the AeDebug registry entry.
For more information about the registry keys used, see Enabling Postmortem Debugging. For more information about register contexts, see Changing Contexts.
Parameters
Address
Specifies the address of the JIT_DEBUG_INFO structure. The address to the structure is passed to the .jdinfo command using the %p parameter that is specified in the AeDebug registry entry.
Environment
Modes | User mode |
Targets | Live, crash dump |
Platforms | All |
Example
This example show how the AeDebug registry entry can be configured to use the WinDbg can be used as the JIT debugger.
Then, when a crash occurs, the configured JIT debugger is invoked and the %p parameter is used to pass the address of the JIT_DEBUG_INFO structure to the .jdinfo command that is executed after the debugger is started.
Remarks
The .jdinfo command uses the AeDebug registry information introduced in Windows Vista. For more information about the registry keys used, see Enabling Postmortem Debugging. The .jdinfo command takes the address of a JIT_DEBUG_INFO that the system set up for AeDebug and sets the context to the exception that caused the crash.
You can use the .jdinfo command instead of -g in AeDebug to have your debugger set to the AeDebug state without requiring execution.
This state can be advantageous, because under usual conditions, when a user-mode exception occurs, the following sequence occurs:
The Microsoft Windows operating system halts execution of the application.
The postmortem debugger is started.
The debugger attaches to the application.
The debugger issues a 'Go' command. (This command is caused by the -g in the AeDebug key.)
The target attempts to execute and may or may not encounter the same exception.
This exception breaks into the debugger.
There are several problems that can occur because of these events:
Exceptions do not always repeat, possibly because of a transient condition that no longer exists when the exception is restarted.
Another event, such as a different exception, might occur. There is no way of knowing whether it is identical to the original event.
Attaching a debugger involves injecting a new thread, which can be blocked if a thread is holding the loader lock. Injecting a new thread can be a significant disturbance of the process.
If you use -c .jdinfo instead of -g in your AeDebug key, no execution occurs. Instead, the exception information is retrieved from the JIT_DEBUG_INFO structure using the %p variable.
For example, consider the following AeDebug key.
Enable Jit Debugging Windows 10
The following example is even less invasive. The -pv switch causes the debugger to attach noninvasively, which does not inject any new threads into the target.
If you use this noninvasive option, exiting the debugger does not end the process. You can use the .kill (Kill Process) command to end the process.
If you want to use this for dump file debugging, you should use .dump /j to add the JIT_DEBUG_INFO structure to your dump file, when the dump file is created.
The JIT_DEBUG_INFO structure is defined as follows.
You can use the dt command to display the JIT_DEBUG_INFO structure.
Viewing the Exception Record, Call Stack and LastEvent Using WinDbg
After the .jdinfo command has been used to set the context to the moment of failure, you can view the exception record returned by .jdinfo, the call stack and the lastevent, as shown below, to investigate cause.
-->User Mode Exception Handling
Exceptions and Breakpoints
The most common application errors are called exceptions. These include access violations, division-by-zero errors, numerical overflows, CLR exceptions, and many other kinds of errors. Applications can also cause breakpoint interrupts. These occur when Windows is unable to run the application (for example, when a necessary module cannot be loaded) or when a breakpoint is encountered. Breakpoints can be inserted into the code by a debugger, or invoked through a function such as DebugBreak.
Exception Handlers Precedence
Based on configuration values and which debuggers are active, Windows handles user-mode errors in a variety of ways. The following sequence shows the precedence used for user mode error handling:
If a user-mode debugger is currently attached to the faulting process, all errors will cause the target to break into this debugger.
As long as the user-mode debugger is attached, no other error-handling methods will be used -- even if the gn (Go With Exception Not Handled) command is used.
If no user-mode debugger is attached and the executing code has its own exception handling routines (for example, try - except), this exception handling routine will attempt to deal with the error.
If no user-mode debugger is attached, and Windows has an open kernel-debugging connection, and the error is a breakpoint interrupt, Windows will attempt to contact the kernel debugger.
Kernel debugging connections must be opened during Windows' boot process. If you wish to prevent a user-mode interrupt from breaking into the kernel debugger, you can use the KDbgCtrl utility with the -du parameter. For details on how to configure kernel-debugging connections and how to use KDbgCtrl, see Getting Set Up for Debugging.
In the kernel debugger, you can use gh (Go With Exception Handled) to disregard the error and continue running the target. You can use gn (Go With Exception Not Handled) to bypass the kernel debugger and go on to step 4.
If the conditions in steps 1, 2, and 3 do not apply, Windows will activate a debugging tool configured in the AeDebug registry values. Any program can be selected in advance as the tool to use in this situation. The chosen program is referred to as the postmortem debugger.
If the conditions in steps 1, 2, and 3 do not apply, and there is no postmortem debugger registered, Windows Error Reporting (WER) displays a message and provides solutions if any are available. WER also writes a memory dump file if the appropriate values are set in the Registry. For more information, see Using WER and Collecting User-Mode Dumps.
DebugBreak Function
If a postmortem debugger has been installed, you can deliberately break into the debugger from a user-mode application by calling the DebugBreak function.
Specifying a Postmortem Debugger
This section describes how to configure tools such as WinDbg as the postmortem debugger. Once configured, the postmortem debugger will be automatically started whenever an application crashes.
Post Mortem Debugger Registry Keys
Windows Error Reporting (WER) creates the postmortem debugger process using the values set in the AeDebug registry key.
HKLMSoftwareMicrosoftWindows NTCurrentVersionAeDebug
There are two primary registry values of interest, Debugger and Auto. The Debugger registry value specifies the command line for the postmortem debugger. The Auto registry value specifies if the postmortem debugger is automatically started, or if a confirmation message box is presented first.
Debugger (REG_SZ)
This REG_SZ value specifies the debugger that will handle postmortem debugging.
The full path to the debugger must be listed unless the debugger is located in a directory that is in the default path.
The command line is generated from the Debugger string via a printf style call that includes 3 parameters. Although the order is fixed, there is no requirement to use any or all of the available parameters.
DWORD (%ld) - Process ID of the target process.
DWORD (%ld) - Event Handle duplicated into the postmortem debugger process. If the postmortem debugger signals the event, WER will continue the target process without waiting for the postmortem debugger to terminate. The event should only be signaled if the issue has been resolved. If the postmortem debugger terminates without signaling the event, WER continues the collection of information about the target processes.
Amy winehouse songs and lyrics. Watch the video for Back to Black from Amy Winehouse's Back to Black for free, and see the artwork, lyrics and similar artists. Amy Winehouse - Back To Black - audio MP3 stream in full for free at UGHH.
void* (%p) - Address of a JIT_DEBUG_INFO structure allocated in the target process’s address space. The structure contains additional exception information and context.
Auto (REG_SZ)This REG_SZ value is always either 0 or 1.
If Auto is set to 0, a confirmation message box is displayed prior to postmortem debugging process being started.
If Auto is set to 1, the postmortem debugger is immediately created.
When you manually edit the registry, do so very carefully, because improper changes to the registry may not allow Windows to boot.
Example Command Line Usage
Many postmortem debuggers use a command line that includes -p and -e switches to indicate the parameters are a PID and Event (respectively). For example, installing WinDbg via windbg.exe -I
creates the following values:
There is flexibility in how the WER %ld %ld %p parameters can be used. For example. there is no requirement to specify any switches around or between the WER parameters. For example, installing Windows Sysinternals ProcDump using procdump.exe -i
creates the following values with no switches between the WER %ld %ld %p parameters:
32 and 64 bit Debuggers
On a 64-bit platform, the Debugger (REG_SZ) and Auto (REG_SZ) registry values are defined individually for 64-bit and 32-bit applications. An additional Windows on Windows (WOW) key is used to store the 32 bit application post mortem debugging values.
HKLMSoftwareWow6432NodeMicrosoftWindows NTCurrentVersionAeDebug
On a 64-bit platform, use a 32-bit post-mortem debugger for 32-bit processes and a 64-bit debugger for 64-bit processes. This avoids a 64-bit debugger focusing on the WOW64 threads, instead of the 32-bit threads, in a 32-bit process.
For many postmortem debuggers, including the Debugging Tools for Windows postmortem debuggers, this involves running the installation command twice; once with the x86 version and once with the x64 version. For example, to use WinDbg as the interactive postmortem debugger, the windbg.exe -I
command would be run twice, once for each version.
64-bit Installation:
This updates the registry key with these values.
32-bit Installation:
This updates the registry key with these values.
Configuring Post Mortem Debuggers
Debugging Tools for Windows
The Debugging Tools for Windows debuggers all support being set as the postmortem debugger. The install command intends for the process to be debugged interactively.
WinDbg
To set the postmortem debugger to WinDbg, run windbg -I
. (The I
must be capitalized.) This command will display a success or failure message after it is used. To work with both 32 and 64 bit applications, run the command for the both the 64 and 32 debuggers.
This is how the AeDebug registry entry will be configured when windbg -I
is run.
In the examples, <Path> is the directory where the debugger is located.
The -p and -e parameters pass the Process ID and Event, as discussed previously.
The -g passes the g (Go) command to WinDbg and continues execution from the current instruction.
Note There is a significant issue passing the g (Go) command. The issue with this approach, is that exceptions do not always repeat, typically, because of a transient condition that no longer exists when the code is restarted. For more information about this issue, see .jdinfo (Use JIT_DEBUG_INFO).
To avoid this issue, use .jdinfo or .dump /j. This approach allows the debugger to be in the context of the code failure of interest. For more information, see Just In Time (JIT) Debugging later in this topic.
CDB
To set the postmortem debugger to CDB, run cdb -iae (Install AeDebug) or cdb -iaecKeyString (Install AeDebug with Command).
When the -iaec parameter is used, KeyString specifies a string to be appended to the end of command line used to launch the postmortem debugger. If KeyString contains spaces, it must be enclosed in quotation marks.
This command display nothing if it succeeds, and an error message if it fails.
NTSD
To set the postmortem debugger to NTSD, run ntsd -iae (Install AeDebug) or ntsd -iaecKeyString (Install AeDebug with Command).
When the -iaec parameter is used, KeyString specifies a string to be appended to the end of command line used to launch the postmortem debugger. If KeyString contains spaces, it must be enclosed in quotation marks.
This command display nothing if it succeeds, and an error to a new console window on failure.
Note Because the -p %ld -e %ld -g parameters always appear first on the command line of the postmortem debugger, you should not use the -iaec switch to specify the -server parameter because -server will not work unless it appears first on the command line. To install a postmortem debugger that includes this parameter, you must edit the registry manually.
Visual Studio JIT Debugger
If Visual Studio has been installed, vsjitdebugger.exe will be registered as the post mortem debugger. The Visual Studio JIT Debugger intends for the process to be debugged interactively.
If Visual Studio is updated or re-installed, this entry will be re-written, overwriting any alternate values set.
Window Sysinternals ProcDump
The Windows Sysinternals ProcDump utility can also be used for postmortem dump capture. For more information about using and downloading ProcDump, see ProcDump on TechNet.
Like the .dump WinDbg command, ProcDump is able to be capture a dump of the crash non-interactively. The capture may occur in any Windows system session.
ProcDump exits when the dump file capture completes, WER then reports the failure and the faulting process is terminated.
Use procdump -i
to install procdump and -u to uninstall ProcDump for both the 32 and 64 bit post mortem debugging.
The install and uninstall commands output the registry values modified on success, and the errors on failure.
The ProcDump command line options in the registry are set to:
ProcDump uses all 3 parameters - PID, Event and JIT_DEBUG_INFO. For more information on the JIT_DEBUG_INFO parameter, see Just In Time (JIT) Debugging below.
The size of dump captured defaults to Mini (process/threads/handles/modules/address space) without a size option set, MiniPlus (Mini plus MEM_PRIVATE pages) with -mp set, or Full (all memory - equivalent to '.dump /mA') with -ma set.
For systems with sufficient drive space, a Full (-ma) capture is recommended.
Use -ma with the -i option to specify an all memory capture. Optionally, provide a path for the dump files.
For systems with limited drive space, a MiniPlus (-mp) capture is recommended.
The folder to save the dump file to is optional. The default is the current folder. The folder should secured with an ACL that is equal or better than what is used for C:WindowsTemp. For more information on managing security related to folders, see Security During Postmortem Debugging.
To uninstall ProcDump as the postmortem debugger, and restore the previous settings, use the -u (Uninstall) option.
How To Enable Jit Debugging On Windows Vista
The install and uninstall commands set both the 64-bit and 32-bit values on 64-bit platforms.
ProcDump is a 'packed' executable containing both the 32-bit and 64-bit version of application - as such, the same executable is used for both 32-bit and 64-bit. When ProcDump runs, it automatically switches the version, if the version running doesn't match the target process.
Just In Time (JIT) Debugging
Fix Jit Debugging Windows 10
Setting Context to the Faulting Application
As discussed previously, it is very desirable to set the context to the exception that caused the crash using the JIT_DEBUG_INFO parameter. For more information about this, see .jdinfo (Use JIT_DEBUG_INFO).
Debugging Tools for Windows
This example shows how to edit the registry to run an initial command (-c) that uses the .jdinfo <address> command to display the additional exception information, and change the context to the location of the exception (similar to how .ecxr is used set the context to the exception record).
The %p parameter is the address of a JIT_DEBUG_INFO structure in the target process’s address space. The %p parameter is pre-appended with 0x so that it is interpreted as a hex value. For more information, see .jdinfo (Use JIT_DEBUG_INFO).
To debug a mix of 32 and 64 bit apps, configure both the 32 and 64 bit registry keys (described above), setting the proper path to the location of the 64-bit and 32-bit WinDbg.exe.
Creating a dump file using .dump
To capture a dump file whenever a failure occurs that includes the JIT_DEBUG_INFO data, use .dump /j <address>.
Use the /u option to generate a unique filename to allow multiple dump files to be automatically created. For more information about the options see, .dump (Create Dump File).
The created dump will have the JITDEBUG_INFO data stored as the default exception context. Instead of using .jdinfo to view the exception information and set the context, use .exr -1 to display the exception record and .ecxr to set the context. For more information see .exr (Display Exception Record) and .ecxr (Display Exception Context Record).
Windows Error Reporting - q / qd
The way the debug session ends determines if Windows Error Reporting reports the failure.
If the debug session is detached using qd prior to the closing of the debugger, WER will report the failure.
If the debug session is quit using q (or if the debugger is closed without detaching), WER will not report the failure.
Append ;q or ;qd to the end of the command string to invoke the desired behavior.
For example, to allow WER to report the failure after CDB captures a dump, configure this command string.
This example would allow WER to report the failure after WinDbg captures a dump.
Security Vulnerabilities
If you are considering enabling postmortem debugging on a computer that you share with other people, see Security During Postmortem Debugging.
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.UnauthorizedAccessException: Access to the path 'C:Program Files (x86)SoftwelRMMS 4.2Miscserver' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream.ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter.CreateFile(String path, Boolean append)
at System.IO.StreamWriter.ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize)
at System.IO.StreamWriter.ctor(String path)
at RMMS.StartApp.writeServerFile(Byte mdbOrSql)
at RMMS.StartApp.sqlServerOK()
at RMMS.StartApp.btnSqlOK_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
************** Loaded Assemblies **************
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5477 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
RMS
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/Softwel/RMMS%204.2/RMS.exe
----------------------------------------
System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5468 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.5467 (Win7SP1GDR.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
RateAnalysis
Assembly Version: 1.0.0.0
Win32 Version: 1.0.0.0
CodeBase: file:///C:/Program%20Files%20(x86)/Softwel/RMMS%204.2/RateAnalysis.DLL
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 8.0.0.0
Win32 Version: 8.0.50727.5420 (Win7SP1.050727-5400)
CodeBase: file:///C:/Windows/assembly/GAC_MSIL/Microsoft.VisualBasic/8.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:
<configuration>
<system.windows.forms jitDebugging='true' />
</configuration>
When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.