It seems that Vista contains lots of interesting new Win32 API calls and some of these provide built in support for deadlock detection… I guess my deadlock detection tool can operate differently on Vista then…
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.
A few weeks ago I wrote about hijacking threads. The principle was good, the code worked but the reason I needed it was flawed so the exercise was a failure. I assumed that it was likely to be a failure when I set out though, so it’s more a confirmation that I need to do things properly rather than hackily…
The idea was the try and outsmart the Windows program loader.
My API hooking currently relies on creating a block of memory in the target process to hold the string that you need to pass to LoadLibraryW() and then calling CreateRemoteThread() and passing the address of LoadLibraryW() as the thread start address and the address of our block of memory as the thread parameter. It works well and even allows you to know if the operation worked, by waiting for the remote thread to terminate and then examining its exit code.
Discovering and then fixing the problem that prevented my tools from running on themselves planted a seed of an idea in my mind. My APIHook library and any code that used it died horribly under leak testing tools such as Purify and BoundsChecker. I’d put it down to me trying to be too clever but not being clever enough and ignored it but it’s a pain to have code that you can’t polish.
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.
When I came back from skiing in Colorado I had a bug report from a client and it took me a fair while to isolate the problem for them. The report suggested that a server that I’d built for them a while back was deadlocking in certain situations. The server had always had deadlock problems due to a couple of poor design decisions that I made early on and I’d built a tool to help me remove the potential for deadlock from it by analysing its lock acquisition patterns - the code was too complex for me to do this analysis by just looking at the code and although I should rewrite the poorly designed section of code I don’t have the time to do so (and it only causes problems when I make changes to the code, which doesn’t happen very often, and the problems can be caught by running my tool).
The size of the “units” that I test with my unit tests varies quite considerably. Usually I tend to work at the single class level; the test will provide mocks for the services that the class requires and the tests will ensure that the class behaves correctly and interacts as expected with the its service providers. Sometimes though the units consist of a whole subsystem, still often a single class, but one which wires up and collects many other classes into a single component; again the service providers that it uses may be mocked but they’re often only right on the edge of the functionality that is being tested.
