JIT Debugging VS2005 beta 2 on Windows Server 2003 X64

JIT Debugging VS2005 beta 2 on Windows Server 2003 X64

• CharlesJ

  Hmm...  I just created a simple native C++ app as such.
  
  

  #define _WIN32_WINNT 0x0501
  #include "stdafx.h"
  #include <windows.h>
  #include <winbase.h>
  int _tmain(int argc, _TCHAR* argv[]){
     DebugBreak();
     return 0;
  }
  
  If I run this (withou debugging) and select the "ProjectName - Microsoft Visual Studio: Visual Studio 2005" it breaks into the debugger as expected.  (I created both an X86 and X64 application).
  
  By default this appears to work.  Did you happen to change any of the default settings
  
  Jeff
  
  

  
  

• Sree2000

  Do calls to System.Diagnostics.Debugger.Break() break into the debugger properly
  
  The CLR's exception handling routines ignore native debug breaks, so it would be expected that a call to kernel32!DebugBreak() would not be caught.
  
  Hope that this helps.
  
  Jeff
  

• Abhi Win

  Hi Jeff
  
  I don't use the CLR and this is all unmanaged native C++
  

• Marcel Meijer

  Yes, that works for me as well. I can only assume that there is some kind of security setting that is preventing my app tripping the JIT Debugger. It is running as a child of an ISAPI extension running in its own IIS Application Pool. Neither the Application Pool or the child will do the DebugBreak yet the ID they are both running under is a member of Administrators.
  I have a standalone Itanium server running Windows Server 2003 with the relevant user id a member of the Debugging group. That works fine. The X64 machine is a domain administrator but doesn't have the equivalent debugging group, hence I tried administrator, still no joy.
  
  Having forced by process to run standalone under my logon id - I have admin rights - it will DebugBreak. So assume security I can attach to both Application Pool.exe and child and debug once they are running.
  
  Thanks
  
  Mick
  
• JIT Debugging VS2005 beta 2 on Windows Server 2003 X64