Because of your description of when and how the bug occurs, I believe it to be a bug in a driver. Perhaps one of the following:
- Video driver
- Network driver
- Hard disk controller driver

A crash like the one you describe should be accompanied by a dump file. Run SYSDM.CPL, navigate to the ADVANCED tab, and hit the settings button for Startup and Recovery. Make sure it's configured to write a dump file ("Write debugging information: Automatic memory dump").

If it's already configured correctly there, then, look for the file C:\WINDOWS\MEMORY.DMP. The file date/time should correspond exactly with the date/time of the most recent crash.

Open up the DMP file in WINDBG if you happen to have that installed. If you don't have WINDBG installed, then I'm sure someone here on the BBS would be happy to analyze the DMP file for you. After the file is loaded, type:

!analyze -v

And it'll give you a verbose analysis of the crash. Among that information is a call stack. Frequently in situations like this you can easily see the name of the offending module right there in the call stack and sometimes a hint as to what the module was trying to do at the time of the crash. The offending module might have a cryptic-looking name like ser2pl64.sys or something, and if you don't recognize it, google for it. (In my example, the name is a USB-to-serial driver for a USB chipset used by some GPS units.)