Last week I mentioned that some of my tests for my Win32 Debug API class had suddenly started failing. It seems that I was right and the changes are due to some .Net fixes that have been rolled out recently. The code runs and the tests pass if I run on a clean instal Vista x64 VM and fail on my day to day development box.
It seems that my plan to “stick a breakpoint in mscoree.
Back in October 2007 I sumarised my findings from getting my Win32 DebugAPI based debug engine working on x64. One of the strange things that I found at the time was this:
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.
There’s an entry over on the Dr. Dobbs blog about testing and how you make sure that your tests are testing the right thing; effectively, who tests the test. There’s a question at the end “What do you do?” and I think my rather pithy, I’ve had some wine, answer is, “I think harder”.
The poster laments the fact that if you’re doing TDD then the test fails first and then you write the code and then it works and therefore you know the test is testing the correct thing but if you have existing code then, well, it doesn’t work that way.
The comments to my last practical testing entry got me thinking. The commenter who had located the bug in part 15, which was fixed in part 16, suggested a new approach to the problem and I’ve been investigating it.
The suggestion is, essentially, to use a timer with a longer range before roll-over rather than GetTickCount() with its 49.7 day roll-over. In Vista and later we could just use GetTickCount64() but on earlier platforms that’s not available to us.
Back in 2004, I wrote a series of articles called “Practical Testing” where I took a piece of complicated multi-threaded code and wrote tests for it. I then rebuild the code from scratch in a test driven development style to show how writing your tests before your code changes how you design your code. Then, in 2005, I adjusted the code to be more scalable and I showed how the tests that had originally been written helped when code needed to be changed for performance purposes.
Back in April 2006 I posted a copy of TickShifter, see here for details. It seems that there was a bug in my Win32 debugger code on which TickShifter is built. The bug was that we failed to “forget about” dlls that were unloaded… Because we failed to forget about them it was possible for the debugger code to try and do something with addresses in these dlls that were no longer loaded and this would cause a C++ exception on the debugger thread when our call to ReadProcessMemory() failed and this caused all sorts of problems…
It’s funny how potential product ideas beget other potential product ideas and the thing that you eventually end up with as a product for sale is often far from the original product idea and the code that you started to write… I’m not even there yet and I’m on my third wave of product idea focus. Right now I’m working towards getting some developer tools out there to help people write better systems.
One of the first things that I tried to do with the latest release of my TickShifter tool was to run it on itself. Of course, that didn’t work.
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.
As I mentioned a while back, I’ve been working on adding rudimentary GUIs to my debugging and testing tools. In fact, both the deadlock detection tool and the time shifting tool are both functional enough for real world use but the command line interfaces make them harder to use than they need to be. I’m not yet 100% sure of the form that the final GUI should take, but I’ve pressed on with my initial GUI development to produce a reasonably complete GUI for the cut down, demonstration tool, TickShifter.
Well, I figure that I’ve written about these debug tools that I’ve been working on for long enough. The time has come to make one available for other people to use and abuse. Given that I hope to sell some of these tools eventually I’ve decided not to give away early versions at present. Much as I will need feedback I think a properly structured beta program would be better for that.
