Reading Windows' Blue Screens

June 17, 2005 11:02 AM

I've managed to get Windows to blue-screen predictably, but I cannot read the screen because the computer immediately reboots. How can I get the information from the blue screen? (bonus if I can fix the problem with that information!)

I'm using JEdit (v. 4.3pre2) on Windows 2000, with the FTP plugin (v. 0.7.4) for transparently editing files residing on an FTP server.

When I start the program, I'm able to edit and save any file on the FTP server approximately a dozen times. The next time I hit File>Save, Windows immediately crashes to a blue-screen and instantly reboots.

I've disabled "Automatically Reboot" in the System Failure section of the Startup and Recovery configuration, and I've verified that the registry value behind this setting is indeed set to zero, but the computer still reboots. I've installed the latest Sun Java VM, but the problem still exists.

There's nothing in the Event Log describing the crash, either, but maybe I'm looking in the wrong place, since there's nothing at all in the Event Log, period.

posted by odinsdream to computers & internet (12 comments total)

You could try hitting the Pause/Break key on the top right of your keyboard...may work. May not...
posted by jaded at 11:21 AM on June 17, 2005

Windows XP should do a core dump if it BSODs. See here.
The simplest solution is to just stop using the offending application. There are plenty of FTP clients that allow on-site editing.
posted by ori at 11:23 AM on June 17, 2005

Look in your event log. Usually Windows will dump the blue screen into the event log. The information that you're looking for is the Stop Code. It looks like this: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000). You can then look it up on one of the following pages:

Microsoft
Not Microsoft

Even if Windows doesn't dump the error, I can usually make out the stop code over the course of a few blue screens. Check out there, the stop code may not provide the answer, but it will help.

That said, if you can cause Windows to blue screen by using that software, then probably the answer is that you need to not use that software. There may be something else that does the same thing that you can use. jEdit uses java. Maybe you need a different release of java?
posted by bDiddy at 11:30 AM on June 17, 2005

Got a camcorder?
posted by ZenMasterThis at 11:33 AM on June 17, 2005

there is a setting in XP and 2000 to re-boot automatically after a blue screen - you'll need to diable this. I leave it your google'ing to find out how to do this.
posted by skwm at 12:04 PM on June 17, 2005

To disable XP's post-crash auto-reboot feature:

1. Right-click on My Computer and choose Properties.
   
2. Select the Advanced tab and click the Settings button under Startup and Recovery.
   
3. Uncheck Automatically restart in the System Failure section.
   

posted by pmbuko at 12:33 PM on June 17, 2005

pmbuko nailed it.
posted by puke & cry at 12:50 PM on June 17, 2005

I hope people read the "more inside" part of the question before answering. If I could re-highlight two important points:

1. I've already disabled the Auto-Reboot On Crash setting that Windows provides for me, but this seems to have no effect. Why?
2. The event log is -completely empty-. This may indicate a larger problem, like some event service not being enabled, but I don't know anything about it. In any case, I can't find any blue-screen core-dump information files in WINNT or C:\, or in the Event Log.

Also, it's Windows 2000, not XP. JEdit has only started doing this since I installed it at work. I haven't had this problem before. I know other software provides similar functionality, but I'd like to continue using JEdit if at all possible. What about different java VMs I could try? I only know of the Sun VM. What others are available for Windows 2000?

The blue-screen goes by so quickly that the only thing I can visually understand about it is that it is, indeed, blue. The CRT has to re-sync to the lower resolution, which takes about a second, so this decreases the amount of time I could read the text anyway.

I'll definitely try the Pause/Break key next!
posted by odinsdream at 2:07 PM on June 17, 2005

You need to look at the location where the dump file is being written to. Does the location exist and is it big enough to write the dump? Also, what type of memory dump have you specified and what location is it being written to? If you have complete memory dump specified and and do not have enough space to write the dump, this type of behavior will happen. Also, is it a valid location? Usually it is %SYSTEMROOT%, which is usually C:\WINDOWS\SYSTEM32. Is "Write an event..." checked? If so you should have a bugcheck event in the system application log. If you do not, it me be cause of the above reasons.
posted by internal at 3:01 PM on June 17, 2005

I've got the Write An Event option checked, but I really don't know how it could possibly have time to write anything. Between clicking Save and rebooting there's maybe a full second, not more.

I do have enough free space on the drive. I'll look in the System32 folder.
posted by odinsdream at 5:21 PM on June 17, 2005

Have you tried hitting the print screen button to capture a screenshot of the BSOD to the clipboard?

Also, does your computer have an Intel hyperthreading processor, or dual CPUs?
If you don't, disregard this.

If you do, try setting your FTP program to only run on one of the CPUs/Hyperthreading-simulated CPU's instead of both. When you first have JEdit up and running, open the task window (CTL+ALT+DEL), right click on the process for the program, and choose "Select Affinity". You will get a list of the CPU's. De-select the check mark for CPU1, leaving only the one for CPU0.

I have done this to solve a ton of BSOD problems for any number of applications.
posted by gemmy at 11:14 AM on June 18, 2005

Just a quick update. Somehow, the event viewer started to magically record this blue-screen dump information. I was also looking in the wrong place for the dumpfile (it was in C:\WINNT\minidump)

Anyway, the problem ended up being Bugcheck 0x000000D1:
When a DLC buffer pool structure is initialized, the number of elements in the array of buffer headers in the pool is being improperly initialized to one too few. As a result, a failure can occur when the largest index element is accessed.

The solution, as discussed in that link, was to install Service Pack 4. That fixed the crashing problem, but the FTP plugin obviously now doesn't work, because of whatever it's doing wrong internally. I expected as much, so no big deal there, but at least it isn't crashing the system now.

Thanks everyone!
posted by odinsdream at 7:47 AM on June 22, 2005