I did something stupid!

[iago]

I left Windows running overnight in VMWare.  I went into work this morning, sat down, and prepared to test some code.  What do I get?

http://www.javaop.com/~ron/images/screenshots/owned-overnight.png

It's weird that it failed in tcpip.sys, though.  I'm wondering whether it's a problem in VMWare or in Windows..

Also, notice all the right at the right -- the red is I/O usage and the green is CPU usage.  I'm not doing anything else on the computer, it was first thing in the morning.  Why's Windows use 100% I/O when it dies?  I'm rather curious about that. 

[Chavo]

It seems plausible the two are related.

[iago]

If you're talking about the 100% I/O, it's not -- it always does that when Windows Bluescreens.  I'm not sure why, though.

[Sidoh]

I don't think I've ever woken up to that (on either my laptop or desktop).

[Chavo]

It does seem strange if you are thinking about it from a application point of view, but if its essentially replacing the OS as the only thing running on the processor, everything is going to be either 0 or 100   The 100% I/O is probably occuring because VMWare is receiving a 'high' signal from the BSOD that it interprets as continually 'high' data from Windows.

Think about it on a lower level.  A high level OS like Windows does 'multitasking' by splitting many jobs into processes and staggers them such that they take turns using the processor power.  The result is rapidly varying states of the processor (and theirfore all of the devices it outputs to, including I/O) that over time can be graphed to show %'s of various states for a given interval.  A low level OS that has no multitasking capability can only run one process at a time.  Therefore the state of the processor and its devices are always equal to those dictated by the process running on it.  If that process is in an infinite loop, the state of the processor will be some infinite function.  Over a time large compared to the period of the function, the function will appear to be flat and the only possible values to graph are 0% and 100%.  I don't know enough about the windows structure to do more than speculate about this, but I imagine the BSOD behaves as its own, non-multitasked OS in an infinite loop.  Therefore all states from the BSOD to VMWare are basically static values.  Why I/O is a static 100% rather than a static 0% is the only part that seems strange.  I don't know enough about the internal workings of VMWare or BSOD to speculate whether its VMWare or BSOD's fault.  Maybe I'll hook up an old machine though, intentionally BSOD it and pull out my multimeter

[Warrior]

With Vista UAC would of prompted you if you wanted to Bluescreen.

[Sidoh]

With Vista UAC would of prompted you if you wanted to Bluescreen.

LOL

[rabbit]

No, sadly it doesn't.  It just happens (I can BSOD at will, not sure if it's a good thing or a bad thing).

[Joe]

I love how you are "Me" is not in the "Me" group, that you only know one real life person ("Me"), and that your coworkers are not real life people.

[MyndFyre]

I can answer a couple of those for you.

When Windows BSODs, it sets the IRQL to 127, the highest it can be in Windows.  That way nothing can preempt the kernel from displaying the bluescreen. 

Windows does nothing when a BSOD hits except for dump the memory file (minidump/kernel dump) in terms of I/O, so that seems to be a VMWare reporting issue.

Want to send me your memory dump (\windows\memory.dmp) or, if you don't have kernel memory dumping enabled, c:\windows\minidump\*.dmp (the file with the most recent date), and I can do a bugcheck analysis for you.

[iago]

I love how you are "Me" is not in the "Me" group, that you only know one real life person ("Me"), and that your coworkers are not real life people.

Yeah, and I collapsed the "Friends" group so people here don't know who I favor (Actually, there's only 2 people from online on my work list, the rest of them are people from real life, I try not to mix my work with online-people. 

The reason I have stupid groups is because it saved them online, and for work purposes I don't need so many.  I really wish I could nest groups on AIM or MSN, but it's impossible (I think). 

Windows does nothing when a BSOD hits except for dump the memory file (minidump/kernel dump) in terms of I/O, so that seems to be a VMWare reporting issue.

It's actually my OS (Linux) reporting that VMWare is using 100% I/O during a bluescreen.  It's definitely reporting right, but it's very possible that it's VMWare being stupid. 

Want to send me your memory dump (\windows\memory.dmp) or, if you don't have kernel memory dumping enabled, c:\windows\minidump\*.dmp (the file with the most recent date), and I can do a bugcheck analysis for you.

If I remember, I might take you up on that, but I don't really care much.  It was just weird. 



<edit> By the way, why do so many people care about this topic?

[Chavo]

I can answer a couple of those for you.

When Windows BSODs, it sets the IRQL to 127, the highest it can be in Windows.  That way nothing can preempt the kernel from displaying the bluescreen. 

Windows does nothing when a BSOD hits except for dump the memory file (minidump/kernel dump) in terms of I/O, so that seems to be a VMWare reporting issue.

Want to send me your memory dump (\windows\memory.dmp) or, if you don't have kernel memory dumping enabled, c:\windows\minidump\*.dmp (the file with the most recent date), and I can do a bugcheck analysis for you.

But if its not clearing that interrupt, it must either loop infinitely inside the BSOD, or continually call the BSOD which would suggest it's dumping every time it gets called (an obviously less than ideal method, but would explain all the I/O...)

[Towelie]

<edit> By the way, why do so many people care about this topic?

There are a lot of people on and this thread is active

[AntiVirus]

Hrmm.....  well that sucks!! </pointless post>

[chuck]

<edit> By the way, why do so many people care about this topic?

Because it has the word 'stupid' in it.