Windows 7 BSOD

[PodgePapin]

I keep getting the BSOD when i try to do anything slightly demanding, i've not added any new hardware (keeps saying remove any new hardware) whilst it does a memory dump (is it just me or does memory dump sound rather rude but very funny). It's only started about a week or so ago and before that i had 1 since testing the beta almost from the beginning. I have a feeling its my Geforce 9600 drivers (version 190.38), im going to try getting last set of drivers... when my net access stops f#@king about and works at normal speeds. has anyone else had issues with drivers?

[Splash]

What is your BSOD error? Also... RC, Beta or RTM?

[watercooled]

Just wanted to say something that might be a comfort to you: I've had 2 BSODs with 7 RC myself and several other people have posted on the forums about getting BSODs also.

[PodgePapin]

its RC, i'll post error next time it comes up

[PodgePapin]

the last error msg i got was (if it helps)

Problem signature:
Problem Event Name: BlueScreen
OS Version: 6.1.7100.2.0.0.256.1
Locale ID: 2057

Additional information about the problem:
BCCode: 124
BCP1: 0000000000000000
BCP2: FFFFFA8004E5D028
BCP3: 00000000B2000040
BCP4: 0000000000000800
OS Version: 6_1_7100
Service Pack: 0_0
Product: 256_1

Files that help describe the problem:
C:\Windows\Minidump\080909-23119-01.dmp
C:\Users\Podge\AppData\Local\Temp\WER-36114-0.sysdata.xml

[Grey M@a]

Almost identical to the ones I kept getting in Win 7 and I moved back to Vista Ultimate 64 because of it, was linked to my chipset and also the following day the 500GB HD stopped responding under Windows 7. In Vista, its found fine and works and there are no errors found on the HD either.

[Paul Adams]

Have you checked for any BIOS updates for your motherboard?

In the BIOS:
- what access mode is the disk controller using, IDE or AHCI?
- have you tried the different disk access modes?

I have seen reports where enabling 32-bit disk access in the BIOS resolved this issue, and previously had systems where AHCI just would not play nicely at all so IDE emulation had to be used.


You could also check in Device Manager under the properties of the disk itself, on the Policies tab - select "Quick removal" for each disk and reboot.
This will disable any write caching for the disk, just to see if it provides stability.

[this_is_gav]

Files that help describe the problem:
C:\Windows\Minidump\080909-23119-01.dmp

Install the Debugging Tools for Windows, open WinDbg, go to File > Open Crash Dump and navigate to C:\Windows\minidump and open that .dmp file above.

It will analyse the .dmp file and give you a likely file or reason for the crash at the end.

Alternatively, upload the .dmp file so we can access it, and we'll give you that info.

[watercooled]

I'd advise compressing it first
BTW I ran my crash dump through that program and it printed 'probably caused by hardware' but I don't think it was - how accurate is it? And sorry if I'm thread hijacking (again) BTW.

[this_is_gav]

I'd advise compressing it first

They're only a few hundred KB. Not exactly gigs.

[watercooled]

Mine was 280MB but then that wasn't a minidump lol.

[this_is_gav]

Mine was 280MB but then that wasn't a minidump lol.

Odd. All of mine are 265kb, both here and at work. :\

[Paul Adams]

Odd. All of mine are 265kb, both here and at work. :\

There are 3 types of dump that Windows 7 can generate on a bugcheck:

Small memory dump
- The bare minimum information that describes what thread was running, the modules loaded and the state of the CPU(s) at the time of the exception
- The size will be 256KB
- This is the type of information sent to the Online Crash Analysis server to help identify known buggy drivers or issues in the kernel

Kernel memory dump
- The working set of the kernel address space, i.e. those resident in physical memory that are used by the Windows kernel and drivers; no user-mode data at all
- The size will be measured in hundreds of MB, up to ~800MB for a busy server
- This can be analyzed with a debugger to get some idea as to what was going on "under the bonnet"

Complete memory dump
- The entire set of physical memory pages in use at the time of the exception; kernel and user-mode data alike
- The size can be up to the amount of RAM in the system, plus a little overhead for the dump file header
- This can be analyzed with a debugger to get a complete picture of what was going on in the kernel and within each process running


A bugcheck will only ever dump memory-resident pages - anything in the pagefile cannot have caused the problem as it would have had to be paged in first, and the pagefile is actually the destination for the dump (after a reboot it is extracted to the relevant .DMP file and an event is logged).


To check which type of dump will be created on a bugcheck:
- right-click on Computer, click Properties
- click Advanced system settings
- click the Settings button in the Startup and Recovery section (bottom)

"Write debugging information" shows the dump type (or "none"), and the dump file location (on extraction) is below that.

On systems with >=2GB RAM, the complete memory dump option is not displayed (it has to be set manually through the registry) as they are rarely required.
A bugcheck can only occur due to an exception in kernel mode, so having the contents of user mode memory is not often useful.

[dangel]

7 defaults to kernel AFAIK

[nightkhaos]

The only BSOD I have had on RC1 for Windows 7 was because of Vdroop when overclocking. It sounds like I was lucky.

[Paul Adams]

7 defaults to kernel AFAIK

Yup, before Vista "workstation versions" of Windows defaulted to minidumps, which meant a manual change to get any useful data and sit & wait for the next bugcheck, which was a pain.
Server versions have always defaulted to a kernel dump, and Vista had this change too.