windows 7 bsod

I had a BSOD just now and the process name and module name that Windbg showed me were dwm.exe and win32k.sys, respectively. I got those from the memory.dmp. Attached is a minidump of that BSOD. I hope you guys can help me :)

anybody?

kevindd992002 said:

I had a BSOD just now and the process name and module name that Windbg showed me were dwm.exe and win32k.sys, respectively. I got those from the memory.dmp. Attached is a minidump of that BSOD. I hope you guys can help me :)

(The process name is irrelevant.)

That's a "rendering" (UI drawing) crash. Try perhaps updating your video driver, if there's an update available. You appear to be using nvidia drivers from mid-August.

Also check that the video card and the PC in general are being adequately cooled.

Oh ok. Well, the driver's I'm using are the latest from Nvidia.

So this is a hardware problem? or overheat? I don't think it's overheating problem since I was monitoring my GPU temps then and they were in the 60s (celsius).

kevindd992002 said:

Oh ok. Well, the driver's I'm using are the latest from Nvidia.

So this is a hardware problem? or overheat? I don't think it's overheating problem since I was monitoring my GPU temps then and they were in the 60s (celsius).

Whatever happened to your "mouse causes processor utilisation" issue? Is this the same machine?

Anyway, there's nothing to suggest this BSOD is hardware. Mentioning (video) cooling is just precautionary in case of rendering crashes like this one. Unfortunately, there's nothing to prove it's software either. All we know for sure from the minidump is that the kernel-mode part of the Win32 GUI (win32k.sys) crashed while dealing with data which was not what was expected. If the cause is in fact software, besides your video driver it could also be things like 3rd-party remote control utilities (VNC?), over-zealous AV, or just a plain buggy driver making wild writes outside of its own data.

A minidump rarely offers certainty, and in this case it's being even more vague than average. The usual starting point in these situations is to "blindly" update all of your drivers: video, audio, NIC, chipset, AV...

H2SO4 said:

kevindd992002 said:

Oh ok. Well, the driver's I'm using are the latest from Nvidia.

So this is a hardware problem? or overheat? I don't think it's overheating problem since I was monitoring my GPU temps then and they were in the 60s (celsius).

Whatever happened to your "mouse causes processor utilisation" issue? Is this the same machine?

Anyway, there's nothing to suggest this BSOD is hardware. Mentioning (video) cooling is just precautionary in case of rendering crashes like this one. Unfortunately, there's nothing to prove it's software either. All we know for sure from the minidump is that the kernel-mode part of the Win32 GUI (win32k.sys) crashed while dealing with data which was not what was expected. If the cause is in fact software, besides your video driver it could also be things like 3rd-party remote control utilities (VNC?), over-zealous AV, or just a plain buggy driver making wild writes outside of its own data.

A minidump rarely offers certainty, and in this case it's being even more vague than average. The usual starting point in these situations is to "blindly" update all of your drivers: video, audio, NIC, chipset, AV...

Oh ok. Got your point.

About the mouse pointer problem, I found the solution. The mouse hover time in the registry was the culprit. I did fiddle with that because it was one of the "tweaks" recommended in Win7 and found out that it was the main problem causing high cpu usage of explorer.exe :) Yup, same machine.

kevindd992002 said:

About the mouse pointer problem, I found the solution. The mouse hover time in the registry was the culprit. I did fiddle with that because it was one of the "tweaks" recommended in Win7 and found out that it was the main problem causing high cpu usage of explorer.exe :) Yup, same machine.

OK, thanks. That was an interesting one from memory. I guess it sort of explains why xperf showed normal-looking activity... there was more of it than usual.

I'm not aware of the precise anatomy of that "tweak" but obviously it wasn't active in safe mode.

Yeah, thanks for the time in helping me regarding that. I wasn't able to reply to that thread since I was really busy.

By the way, what does a process name signify in minidumps?

kevindd992002 said:

Yeah, thanks for the time in helping me regarding that. I wasn't able to reply to that thread since I was really busy.

By the way, what does a process name signify in minidumps?

Very little :)

It's the name of the process whose thread crashed the machine, and although that sounds very significant, for reasons that are not simple to explain it is in fact almost completely irrelevant.

You can safely ignore that part of the output.

Ok :) thanks..