DbgPrint

[TWell]

**** NOTICE: Tested on Windows 10 64 ****

With msvcrt.dll, 32bit and 64bit versions.

[jj2007]

**** NOTICE: Tested on Windows 10 64 ****

Works fine on Win7-64. The 64-bit version shows some extra non-identified events, though.

[GoneFishing]

The 64-bit version shows some extra non-identified events, though.

And what are they?

[TWell]

some other exception 4000001F STATUS_WX86_BREAKPOINT ?

0x4000001F
STATUS_WX86_BREAKPOINT
An exception status code that is used by the Win32 x86 emulation subsystem.

[GoneFishing]

It makes sense.
It's x64 specific:
Using the Windows debugging API on Windows 64 :

However some of the output produced is a little unexpected! After all, we are debugging exactly the same process that we debugged earlier under "Next step - running the 32-bit code on 64-bit" but we are getting much more output and a very different call stack on program exit. What is going on?

The first change when using the 64-bit debug API is that the debugger is notified about additional DLLs loaded into the process address space. The first DLL loaded, ntdll.dll, is in fact the 64-bit version of the DLL and it is followed by the 32-bit ntdll32.dll. Note that the 32-bit mode debugger doesn't see the 64-bit DLL, only the 32-bit one.

The next few DLLs are the WOW64 implementation - these are 64-bit DLLs loaded into the target process. Again, the 32-bit mode debugger does not receive any notification when these DLLs are loaded into the process. Notice however that, probably through an oversight in the implementation of the 32-bit debug interface, the 32bit debugger sees the UNLOAD DLL messages for the special WOW64 DLLs.

We then receive an unexpected exception - code 0x4000001f - which turns out to be a new value, STATUS_WX86_BREAKPOINT. This exception code is barely documented but it appears to be a 'start up' breakpoint much like the initial breakpoint that the debugger always receives.  On older versions of Windows the default processing for this exception code terminates the process, on Windows 7 it is ignored.

The author of the article fixed this problem like this:

Code Select Expand


case EXCEPTION_DEBUG_EVENT:
    if (!attached)
    {
      // First exception is special
      attached = true;
    }
#ifdef _M_X64
    else if (DebugEvent.u.Exception.ExceptionRecord.ExceptionCode ==
             STATUS_WX86_BREAKPOINT)
    {
      std::cout << "WOW64 initialised" << std::endl;
    }
#endif // _M_X64
    else
    {
      OnException(DebugEvent.dwThreadId,
        DebugEvent.u.Exception.dwFirstChance,
        DebugEvent.u.Exception.ExceptionRecord);
      continueFlag = (DWORD)DBG_EXCEPTION_NOT_HANDLED;
    }
    break;

I'll add it to the code of the Launcher
Should I use _M_X64 define for Windows 7 64 /Windows 10 64 ?

[GoneFishing]

Does it heart that you have to terminate it by pressing Ctrl-C ?

[jj2007]

Does it heart that you have to terminate it by pressing Ctrl-C ?

Yes it hurts, but that is easy to fix:

         case EXIT_PROCESS_DEBUG_EVENT:
         // Display the process's exit code.

                     //MessageBox(0, "Bye", "Debugger:", MB_OK);
                     return;
         //   dwContinueStatus = OnExitProcessDebugEvent(DebugEv);
            break;

[GoneFishing]

Ok , it'll be fixed
Also make  change in  default case of exception handling switch:

Code Select Expand

   default:
               // Handle other exceptions.
                  printf("-- other exception with code 0x%08X \n", DebugEv->u.Exception.ExceptionRecord.ExceptionCode);
                  break;
You won't see non-identified events any more

[EDIT] Fixed version attached,  STATUS_WX86_BREAKPOINT is not handled  - I still don't know how to ifdef it for x64 target

[jj2007]

Hi GoneFishing,

Based on your source, I've written a plain assembler version. The exe is 1536 bytes and handles only debug string messages, i.e. if there are no problems, the target exe will behave as if it was not debugged at all.

Test it with this snippet:

Code Select Expand

include \masm32\include\masm32rt.inc
.code
start:
  mov ebx, rv(GetProcessHeap)
  invoke HeapAlloc, ebx, 0, 20
  xchg eax, esi
  mov byte ptr [esi+48], "x"    ; <<<<<<<<<<< ILLEGAL!!!
  invoke HeapValidate, ebx, 0, 0
  print LastError$()
  invoke HeapFree, ebx, 0, esi
  print LastError$()
  exit
end start

EDIT: Attachment removed, an improved version is now at \Masm32\MasmBasic\Res\DebugHeap.exe; see
HeapValidate doesn't find any problems