Since it always reproduces, it should be pretty easy to figure out what is going on (at least for a developer with sources and symbols). Before trying to debug it though, I’d suggest checking the drivers for your USB host and your USB hub making sure they are up-to-date.
Start by enabling user-mode crash dumps in Windows Error Reporting. There is a link my original post and someone else responded by pasting the instructions. Then reproduce the crash and locate the crash dump.
[EDIT] Here is the link explaining how to generate crash dumps with Windows Error Reporting. If you don’t want to try to figure this out on your own, just generate the crash dump and include it with your bug report. That said, if you have the ability to dig into it a bit more, it would be worth trying to confirm where the crashing code lives so that you have some leverage to get somebody to look at it. It would be even more useful if you could do enough root cause analysis to determine who really owned the bug (i.e. it could be a Thrustmaster problem or a Windows issue). Unless this is a widespread issue, it might be hard to get anyone to look at it, so the more info you can provide, the better.[/EDIT]
If it were me, I’d open it in a debugger. Both Visual Studio and WinDbg (which is available for free with the Windows SDK) can open crash dumps. In either case, I’d set my symbol path to pull from the Microsoft symbol servers.
Looking at the crash dump in the debugger, I’d start by examining the stack to see if I got any symbols loaded and they gave me any hints. What I would hope for is symbols at the top of the stack, which might mean that I can conclusively identify the actual function where the exception occurs and whomever I send the bug report to won’t be able to blow me off (at least not initially–the root cause might still lie elsewhere, but at least I can force somebody to take a look). Actually, the symbols might not be right, so I would still check the address against the loaded module list to definitively identify source of the crash. Otherwise, I look lower–often retail bits are compiled with Frame-Pointer-Omitted and there are other optimizations that result in a less than complete stack. Anyway, my point is even if there is a symbol several frames down, it might still be in the module that is the culprit. In any case, I would look at the crash address and then dump the loaded modules in order to at least determine which module the crash is occurring. Again, that gives me incontrovertible proof of the culprit which means my bug report shouldn’t be dismissed.
Then, if I can, I want to form a hypothesis on the actual cause. First thing is to look at the disassembly where the crash occurs (and consider the actual exception code and its implications). If I have a symbol, I might be able to infer what the surrounding code is doing by the name, but we have to be careful because retail symbols are usually inaccurate. So I will probably take it with a grain of salt, but for example, if I think I’m in strcpy and the crash is in a REPNE, well I might give the symbol a bit more credence.
In addition to the instruction at the time of the crash, I’ll look at all instructions leading up to the crash and examine register values. Although I can only do that for one instruction per register, it can often be very useful. For example, maybe RCX is some ridiculously high value and maybe from that I can deduce that we ran off the end of a string or a loop terminator failed or something like that. Then what I really want is a memory dump. If I have that, I can cruise the memory state at the time of the crash. I would definitely try treating the contents of any register (for which I was uncertain as to its use) as a possible pointer to a string to see if any possibly interesting strings turned up in memory. If there were any data structures that I thought those values would represent, I’d also try casting the addresses to pointers of those types. Sometimes you get lucky. Anyway, the more information you can discover, the more likely it is that you can form a hypothesis as to the root cause.
For a crash with a ThrustMaster, particularly 0xc00000005 (which is an access violation), I’d be expecting to find a MOV instruction either reading to or writing from/to whatever port is assigned to the Thrustmaster USB device. If I felt really masochistic, I’d probably try to reverse engineer the USB stack. That said, I wouldn’t be surprised to chase the problem all the way to the hardware. It quite possibly could be a bug in the USB host or even the joystick itself. If I knew that I had the latest driver, I might be tempted to pull the cover off the machine and try to find the USB host chip (I’d probably start by trying to find docs for the chip). If I could, I might try some hardware hacking tricks to try to get some visibility into the chip behavior as well as monitor incoming and outgoing bus signals.
Of course, the above depends on how motivated I was feeling, whether I had a workaround and whether I was getting good support from whomever owned the buggy code.
