This entry's really just so that I don't forget where I found the link...

Oh, and this link is really useful to, though I've already been bitten by and fixed most of the issues that are mentioned.

• A 32bit exe can't start a 64bit exe for debugging - pretty obvious really.


• When a 64bit debugger is running a 32bit debugee the debugger seems to get TWO "loader breakpoints" one when the 64bit dlls are loaded and a second when the 32bit dlls have been loaded.


• In a 32bit debugger running on WOW64 a call to DebugSetProcessKillOnExit() succeeds but doesn't seem to do what it's supposed to do.


• When a CLR process is started on an x64 machine you can't rely on the image type of the stub to tell you if it will be a native x64 process or an x86 process; the stub for a .Net 2.0 process can be x86 yet can still cause a native x64 CLR host to run the app...


• When running a CLR app under the Win32 debug interface you only ever seem to hit the native entry point if you're running under WOW64. In all other situations you don't hit the native entry point ever. If you rely on it to pause your debug tools once the process is completely loaded and ready to roll then you need to stick a break point in _CorExeMain in mscoree.dll. What's more, if you're on x64 you might not even be able to access the native entry point's memory...


• When injecting a dll into a process using the "Richter" thread calls LoadLibrary() approach remember that a) the dll image type (x86/x64) must match the process image type and b) if you're injecting into a 32bit process from a 64bit process you'll need to enumerate the modules in the 32bit process to get the HMODULE to Kernel32.dll so that you're function pointer to LoadLibrary() is offset correctly...

Anyway, when starting a native process under the Debug API it was always easy enough to set a break point in the process' entry point and halt the debugger at that point so that I could inject code and fiddle around. On XP I found that managed processes never hit the native entry point that's written into the PE file and so I had to spot that the process was managed and shove a break point into _CorExeMain in mscoree.dll as that was the nearest alternative. Under x64 using .Net 2.0 I still have to do this (and what's more the entry point in the PE isn't in writable memory, so perhaps it's an offset to a managed entry point...). However, when running with .Net 1.0 or .Net 1.1 on x64 I end up with the WOW64 layer coming to life (which complicates matters a little) and the native entry point IS hit as you'd expect... An added complication is that I can't just use the code that assumes that the native entry point wont be hit and ignore it if it is because under WOW64 I start getting notifications from other threads before my managed entry point is hit and I need to gain control before other threads are running...

Fun, fun, fun... The good news is that I know what's going on now and I expect I can build in some checks that will work out how to take control of the processes that are being started up. I don't really want to look at the managed debug api just yet as that's not really what I need...

When running my Win32 debugging code on x64, this time when compiled natively as x64 code and when debugging an x64 CLR process, I've been getting an 'unexpected' ExceptionCode in an EXCEPTION_DEBUG_EVENT. The code is 0x4000001f and, after some searching around, it seems that it's a STATUS_WX86_BREAKPOINT event and I sometimes get these instead of EXCEPTION_BREAKPOINT events...

What's more, changing my code to terminate the process forcibly, with TerminateProcess() if my wait for the debugged process to terminate cleanly times out also fails... The call to TerminateProcess() returns without error but the process is still alive and remains that way until the debugger process itself terminates...

The end result of this is that if you try and run TickShifter on an executable that happens to load and then unload a dll during process start up then it probably wont work very well... Internet Explorer is one such executable...

Product 2 was something that I, rather grandly, named Mock32. The idea being that you could use it to do things like this:

   CMockEvent mock;

   mock.Expect(_T("CreateEvent"))
      .Taking(_T("lpEventAttributes"), CNullPointer())
      .Taking(_T("bManualReset"), CFunctionCallData(FALSE))
      .Taking(_T("bInitialState"), CFunctionCallData(FALSE))
      .Taking(_T("lpName"), CNullPointer());                   // Should be able to specify returning 'index 1'
                                                               // or extract the return value?
   mock.Expect(_T("CloseHandle"))
      .Taking(_T("hObject"), CFunctionCallData())              // Should be able to pass 'index 1'
      .Returning(_T("hObject"), CFunctionCallData())
      .Returning(CFunctionCallData(TRUE))
      .LastError(ERROR_SUCCESS);

   {
      CAutoResetEvent event;
   }

   THROW_ON_FAILURE(functionName, true == mock.Verify());

And test the lowest level of your code by using mocking and dependency injection techniques to replace and control parts of the Win32 API.

It works. The code above and much more are now part of my Win32Tools test harness suite. My problem was one of moving the workingish code to a product and dealing with the questions of licensing and whatever. It was clear, at the time, that although I could use this stuff it wasn't necessarily easy for anyone else to use; what's more, I'm not even sure that anyone else would want to test at this level...

The more useful tests being ones where you have the mock fail a call which is often complex to force a failure in unexceptional conditions...

   CMockEvent mock;
  
   mock.Expect(_T("CreateEvent"));
  
   mock.Expect(_T("SetEvent"));
  
   mock.ExpectAndReturn(_T("SetEvent"))
      .Returning(CFunctionCallData(FALSE))
      .LastError(ERROR_NOT_ENOUGH_MEMORY);
  
   mock.Expect(_T("CloseHandle"));
  
   {
      CEvent event(0, CEvent::AutoReset, CEvent::NonSignaled);
  
      event.Set();
  
      THROW_ON_NO_EXCEPTION(functionName, event.Set);
   }
  
   THROW_ON_FAILURE(functionName, true == mock.Verify());

The way the mock is set up above it causes the second call to ::SetEvent() that is made to fail and return FALSE with a lastError of ERROR_NOT_ENOUGH_MEMORY. This allows us to force execution of the error handling code path in the class under development; something that would otherwise be extremely difficult to do.

This is the code that I originally developed my code generator for. The code generator can generate much of the code that is required to mock an API by simply running it on the appropriate section of a windows header file.

This is also the code that Roy Osherove's comments convinced me to change from a purely log based mock system to one which used expectations. You'll note the JMockesque style of the mock setup. This was well worth doing and moved the code slightly nearer to being something that someone other than me would find useful.

There are several reasons why the tool might have had problems running on itself but I thought I'd addressed most of them when I dealt with the issues around getting multiple copies of the tool running at the same time. The problems there were mostly around the names that I used for the named kernel objects that were required; the control program communicates with the dll that it injects so that it can control the dll's operation and collect data. This communication requires some named objects, pipes, shared memory, events, etc, so that the dll can correctly hook up with the control program. Initially these names were fixed and that meant that only one instance of the tool could run at a time, adding the process Id of the running instance of the tool to the names fixed that little problem.

The problem I had was that to inject the dll into the target process the control program needs to find out the address of LoadLibrary() in itself and, since it's implemented in Kernel32.dll, and that's always loaded in the same place in all processes, that address is the same in the target process. The result of this is used in the call to create a remote thread in the target process and this remote thread loads the dll into the target. My problem was that in the tool that was running under a tool, the address that I was getting back from GetProcAddress() for LoadLibrary() was the address of the hooked function in the tool process and not the address of the real function in Kernel32. Since the hooked function only existed in the hooked tool and not in the target process the target process died with an access violation when the remote thread tried to call LoadLibrary().

It's a fairly obvious problem once you realise what's going on. Of course getting to that realisation stage took a while. Debugging debuggers that inject code into target processes isn't the simplest thing in the world and I ended up doing it the "old fashioned way" with OutputDebugString(). This also wasn't as easy as it could have been because my tool, the control program, is a Win32 debugger and, as such, it receives the OutputDebugString() output from all of its child processes. So, to see that child process output I needed to have the debugger call OutputDebugString() on the strings that it was passed via the EXCEPTIONDEBUGINFO structure...

Once I'd located the problem, solving it took a little while. The obvious solution is to simply provide the real address when required. Unfortunately, possibly due to my design, that's a little harder than it should be. When I fixed the code so that it worked with the tool that had been hooked by another tool the tool that wasn't hooked stopped working... Eventually I figured it out and the latest, as yet unreleased, version of TickShifter can now shift the ticks on an instance of itself which can shift the ticks on an instance of itself, etc...

The GUI is fairly simple.

Simply browse for, or type in, a target process, select how you want to adjust the results of its calls to GetTickCount() and hit the "Launch" button.

Once you're running a process under the tool you'll see the "session" listed in the sessions list. A session is a collection of data from one or more processes under test. Each time you hit the "Launch" button you create a new session. Viewing the session data shows you the processes that were monitored during the session. If the process that you launched didn't launch any child processes then this dialog will simply list one process. The multiple-process support isn't especially useful for the simple TickShifter tool (but then it is just a minimal example of how the tools work!), it's much more useful for the Deadlock detection tool as it allows deadlock detection to operate on named kernel objects across processes rather than simply within a single process.

From the session display you can navigate to each individual process. The TickShifter GUI simply displays all of the calls that the process has made to GetTickCount() more complex tools might show a tab for each lock that's accessed by the process, another tab for each thread, another showing the overall ordering of lock access within the process, etc. The number next to each entry is the location that the call occurred at. Clicking on the location takes you to a call stack display.

And that's about it. If you come across buttons that never become enabled that's because the code isn't finished. Likewise the "namespace" removal stuff doesn't yet work; once it does it will allow you to make the call stack display easier to read by being able to specify namespaces that you'd like stripped from function names.

I quite expect that this will fail to work on your machine, but I'd like to know if it does so that I can fix it! Comments and suggestions welcome, as always.