2

On a Windows Server 2008 R2 Server with Remote Desktop Services installed and multiple users logged on, the Visual Studio Just-In-Time Debugger window may appear on any RDP session, not necessarily the session whose actions caused the error.

The errors are occurring in a Classic ASP application that uses a legacy VB6 COM object and a SQL Server database. It seems that an error in the w3wp.exe process doesn't know which RDP user's browser session initiated the actions leading to the error, so it selects an RDP session at random in which to spawn the JIT Debugger window. While the dialog is displayed, the Classic ASP application freezes for everyone, regardless of which RDP session they are in or whether they are accessing the app remotely. To make matters worse, the window tends to appear underneath the user's active windows. To get out of the situation, one must ask every person with an RDP session on the machine to look for the JIT Debugger window and cancel it.

Is there anyway to force the JIT Debugger window to appear in a particular user's RDP session - preferably the session of a user who wants to debug the process?

Zarepheth
  • 121
  • 1
  • 6
  • The best way would be to fix the bug in the ASP app. Of course you can also write a code, that would periodically search running processes & kill the debugger – Vojtěch Dohnal Jan 05 '16 at 21:14
  • 1
    The thing is, in order to fix the error we must first trouble-shoot it with the debugger... – Zarepheth Jan 05 '16 at 23:28
  • Perhaps launching Visual Studio manually and attaching to the `w3wp.exe` proccess would work for that particular RDP session & user? If the user is local admin, he could also kill the other user's debugger from ProcessExplorer. – Vojtěch Dohnal Jan 06 '16 at 07:19
  • I had the only active session for a while yesterday evening (there were also some disconnected sessions). At that time the window always appeared in my session. However, I was unable to find the w3wp.exe process in the Debug-Attach window before the error occurred. So even with Visual Studio running, I still got the JIT Debugger window and after all the prompts it still wanted to open a new instance of Visual Studio. – Zarepheth Jan 06 '16 at 14:13
  • @VojtěchDohnal I'll have to try killing the process via Task Manager. – Zarepheth Jan 06 '16 at 14:16
  • @Zarepheth Did you tried the tip I gave to open the RDP session with mstsc /console to make your test ? Like I told the debugger need a console's session – yagmoth555 Jan 06 '16 at 15:40

1 Answers1

1

As it's on a Terminal Server and on a server in production, Uninstall Visual Studio.

JIT Debugger install itselft when you intall Visual Studio.

I strongly recommand to use a local computer for your coding's need,as JIT need a console windows.

Enabling or disabling Just-In-Time debugging

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.

Click OK.

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:

[assembly:System::Diagnostics::DebuggableAttribute(true, true)]; 

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:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger

If your computer is running a 64-bit operating system, delete the following registry keys also:

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger

Take care not to accidentally delete or change any other registry keys.

Close the Registy Editor window.

Just-In-Time debugging errors

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.

From: https://msdn.microsoft.com/library/5hs4b7a6%28v=vs.100%29.aspx

yagmoth555
  • 16,300
  • 4
  • 26
  • 48
  • The server is actually used for development and testing, rather than production. However, they expect multiple developers and testers to be on it at the same time... I agree that having the application fully installed, with Visual Studio and all other needed tools on each developer's machine is best, but that's out of my hands. – Zarepheth Jan 05 '16 at 22:15
  • @Zarepheth - I doubted that you wasnt able to remove it. I pasted how to remove the JIT for that. If you need it, try mstsc /console in worst case, as the debugger windows need a console session. – yagmoth555 Jan 05 '16 at 23:43