none
Mysterious VS JIT debugger invocation failure RRS feed

  • Question

  • I've got a mystery.. I can't make the VS 2005  JIT debugger automatically invoke any longer. It used to work properly until yesterday. An application crash would bring up the standard crash requester with the "debug" option. Clicking Debug would bring up the VS 2005 IDE and I'd be happily debugging.

    But now.. I click "Debug" and nothing happens. The crash dialog disappears and nothing, just my Windows desktop.

    VS is working with no problem. I can use the IDE, compile, everything. I can also use the debugger directly by attaching to a running process. So the actual debugger works with no issues.

    So I tried to go through all the steps why the JIT debugger wasn't starting up. I went into VS 2005 Options, and made sure JIT was turned on... it was. I turned it off, quit, restarted, and turned it back on, since maybe that'd reset the registry keys.  Nope, still same symptoms.

    I checked the registry directly. The AEDebug keys seem correct. In particular, the Debugger entry is the proper "C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld  . I compared them to my second machine (which is identically configured but MS2005 does work).

    To figure out if it was Windows or VS2005, I downloaded and installed WinDBG. I used winDBG -I to install it as the default debugger, which basically replaces the AEDebug  Debugger entry with a call to WinDBG. Works fine! So Windows seems to be calling the designated Debugger OK.

    Went back to MS 2005 and reactivated JIT (it realized it was no longer set to be the default). Back to no JIT.

    Whew! OK, so I tried a repair installation of MS2005 to make sure all the files were fresh.  No change.. still no JIT. (I double checked the JIT settings too).

    OK, maybe the vsjitdebugger.exe is corrupt or something. I deleted it manually, and reinstalled MS2005 (yet again).  It replaced the missing vsjitdebugger.exe with a fresh copy.  But nope, still nothing happens.. I click Debug in the crash requester, and nothing, the dialog just closes

    I then tried to manually run the debugger from the command line.  vsjitdebugger.exe /? gives usage, you basically use a -p command line flag with a Process ID.  OK, I start Notepad, use Task Manager to find the PID, then manually execute vsjitdebugger -p <xxxx>  with notepad's PID.

    Now I get a VERY INTERESTING error message. vsjitdebugger responds with a modal dialog titled "Visual Studio Just-in-Time Debugger". The text says  "Select a debugger to attach to Notepad.exe[2672]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on.  Check the documentation index for 'Just-in-time debugging, errors' for more information."

    Ah hah! I'm getting no JIT response since vsjitdebugger.exe is hitting this error and silently exiting. When I invoke vsjitdebugger manually, I can see the error.

     

    BUT what the heck is this "no user is logged on" problem?    The error message (and docs) clearly state that you'll get this error if you're debugging remotely and nobody is actually logged in, but that's not the case.. I'm debugging on my own machine, in a normal account, there's no remote stuff going on at all. Mysterious!

    I can go to Task Manager, Users tab, and even see that I'm logged in, ID 0, Status Active, Session Console. So Windows does know I'm there, and knows my account is a Console, so the debugger should work. :-)

    I'm running plain Windows XP Pro, using a normal account (It has administrator privileges). I created a couple more accounts to try both with and without administrator privileges and all types fail.  (That also confirms that it's not a user account setting, it's something machine-wide).

    And now I'm stuck. I don't know what "broke"  nor how to fix it anymore. And I never realized how much I depended on VS's great JIT debugger.. I feel blind now.

     

    I appreciate any help, any clues, any guesses. My own thoughts now are maybe this is some Windows configuration error or registry damage, and that's confusing vsjitdebugger.  I don't have any other symptoms in any program or in the MS IDE at all.

     

    Thanks thanks thanks to anyone who has any comment or ideas.  This is really important to me.

     

     

     

     

     

     

     

    Monday, July 31, 2006 3:45 AM

Answers

  • Gregg, thanks for the followup!  That's excellent detailed information. No, the problem was quite persistent even with reboots, different user accounts, and many different experiments.

    I actually opened a support issue with MS about this problem, but in the end found out by random experimentation that it was registry related to the WinLogon keys.  I copied the key settings from my laptop (with working JIT) to my main machine and suddenly JIT worked again.

    It was the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify  subkeys.. I copied them all so I don't know which one specifically was the problem, nor how it could have been broken.

    Thanks for answering!

     

     

    Tuesday, August 29, 2006 9:30 PM

All replies

  • What is happening is that when vsjitdebugger.exe calls CoCreateInstance on CLSID {36BBB745-0999-4FD8-A538-4D4D84E4BD09}, COM returns CO_E_RUNAS_LOGON_FAILURE. Normally CO_E_RUNAS_LOGON_FAILURE happens because a service crashes at a time when no one is logged on, so we display 'no user logged on'.

    Now the more interesting question is this -- why is COM returning CO_E_RUNAS_LOGON_FAILURE. Here is a nice hope -- is there by any chance something useful in your event log? I am assuming that you already tried the magic cure-all (the reboot).

    Gregg Miskelly
    http://blogs.msdn.com/greggm

     

    Wednesday, August 16, 2006 5:45 AM
    Moderator
  • Gregg, thanks for the followup!  That's excellent detailed information. No, the problem was quite persistent even with reboots, different user accounts, and many different experiments.

    I actually opened a support issue with MS about this problem, but in the end found out by random experimentation that it was registry related to the WinLogon keys.  I copied the key settings from my laptop (with working JIT) to my main machine and suddenly JIT worked again.

    It was the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify  subkeys.. I copied them all so I don't know which one specifically was the problem, nor how it could have been broken.

    Thanks for answering!

     

     

    Tuesday, August 29, 2006 9:30 PM
  • I had exact same problem,  After I saw your post I compared my WinLogon\Notify key with another dev box and noticed that it's missing SensLogn handler key.

    After importing the key and rebooting, JIT Debugger window showed up as expected.

    Here is the reg file.
    --------------------------------------------------------
    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\SensLogn]
    "DLLName"="WlNotify.dll"
    "Lock"="SensLockEvent"
    "Logon"="SensLogonEvent"
    "Logoff"="SensLogoffEvent"
    "Safe"=dword:00000001
    "MaxWait"=dword:00000258
    "StartScreenSaver"="SensStartScreenSaverEvent"
    "StopScreenSaver"="SensStopScreenSaverEvent"
    "Startup"="SensStartupEvent"
    "Shutdown"="SensShutdownEvent"
    "StartShell"="SensStartShellEvent"
    "PostShell"="SensPostShellEvent"
    "Disconnect"="SensDisconnectEvent"
    "Reconnect"="SensReconnectEvent"
    "Unlock"="SensUnlockEvent"
    "Impersonate"=dword:00000001
    "Asynchronous"=dword:00000001


    Thursday, April 19, 2007 11:45 PM
  • BTW Same problem prevented Windows Update from applying the updates when checked manually.  It would only work if update service automatically downloaded and applied updates w/o UI.  Now Windows Update works properly.  Candidate for KB article for Windows Update problems ? ;-)
    Thursday, April 19, 2007 11:51 PM
  • Yeah, a KB article would have been great.. I used 8+ hours trying to solve this problem last year.

    It stumped MS developer support, too... it was close to a "format the hard drive and reinstall everything from scratch" point.

    Luckily I had a nearly identical, but working, system to keep comparing everything with, but it wasn't obvious it was anything registry related.

     

     

    Monday, April 23, 2007 12:43 PM
  • I actually found that none of this helped, but I fixed this issue - or perhaps my issue was similar but not equal since in my case nothing was displayed at all. There was recorded an Event in the Application Log, from VsJITDebugger Event ID 4096:

    "An unhandled Microsoft .NET Framework exception occurred in WindowsApplication1.exe [2860]. Just-In-Time debugging this exception failed with the following error: The operation attempted is not supported.

    Check the documentation index for 'Just-in-time debugging, errors' for more information."

    The answer I found at the Microsoft Connect topic below, even though that was not exactly what I did either.

    I found that the registry key HKCR\AppID\(curlybraceopen)E62A7A31-6025-408E-87F6-81AEB0DC9347(curlybraceclose) listed 0x28 on the computer on which the debugger didn't show the dialog and it was listed as 0x8 on the computer on which this worked just great.

    The fact that the Connect article shows this issue as fixed in VS2013 - the version I'm using - while I still get this problem, is perhaps due to the fact that I installed VS2012 after VS2013 because I found that I needed the VS2012 C++ compiler for my project.

    That registry key is actually the registry key for Visual Studio JIT Debugger.

    Here's the link: https://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported

    So after changing that value to 0x20 and finding it had no effect, I changed it to 0x8 and promptly my Debugger.Break statement will properly show the VS JIT Debugger dialog to select the debugger.

    • Proposed as answer by The Evil Otto Monday, October 30, 2017 10:12 AM
    Monday, December 9, 2013 4:16 AM