All of that is probably valid, correct, and do-able. Knowing that the problem appeared inconsistently, and not knowing what might be causing the problem or what caused the occasional successes, I decided to stick with a real Mac and no VM, just to rule out all the variables that a Hackintosh and/or VM would introduce. I don't have a serial port, and didn't want to invest the time in acquiring one and getting it to work, so I did it the hard way. (That seems to be a habit of mine, unfortunately.)
It's quite limited in scope, since it was tailored for this project. It basically grabs control as soon as the display is usable, lets me examine memory, step through the thread list, dump and trace the stack of each thread, etc. It's crude, but effective enough to get the job done. The very first time the debugger ran successfully (trust me, I've generated more kernel panics than all other MacRumors members combined), I got a great adrenaline rush because that boot triggered the deadlock, and I got a clean stack dump that laid out the roadmap that eventually led to the solution. That was a good day.
(Before anybody asks: I have no plans to release this debugger. It was a quick and dirty (and, frankly, ugly) hack that was custom-built for this purpose. With any luck, it will never be used again.)
