BSOD Help Please

euckersw · 18 Nov 2010

I did some additional searching around and am wondering if there's a way to use the standard PCIIDE.SYS MS drivers rather than the NVSTOR/NVSTOR64 drivers? When I try to manually update the driver within the Windows Device Manager, it provides the "Standard Dual Channel PCI IDE Controller" (which includes the PCIIDE.SYS driver) as an option. If I select that driver, I'm forced to restart, and when I do Windows appears to automatically update the driver back to the NVIDIA NVSTOR driver. Would it be worth trying to change the NVSTOR/NVSTOR64.SYS drivers to .BAK files so that Windows can't override my selection of the generic drivers? I don't want to do anything that's going to crash my system for good, but at the same time, I really don't want to be using these NVSTOR drivers as I get the feeling they are causing my BSODs. Any thoughts? Thanks again for your help.

-Scott

CarlTR6 · 19 Nov 2010

I would not rename those to .bak. What I would do is go to the NVidia website and ask there support what you should do. They have a forum there also. The issue may be discussed in the forum. The best option for updating drivers is to download the latest from the manufacturer's website and install them yourself.

euckersw · 20 Nov 2010

I have confirmed that I am running the latest versions of NVSTOR.SYS and NVSTOR64.SYS.

Here are a few more updates/things I've tried:

- Yesterday I ran the computer for over 24 hours in safe mode without a BSOD.
- This morning I unplugged my NVIDIA video card and my DVD-ROM (which is also using a SATA connection). Therefore I was using the original on-board video card. I then booted up into regular (non-safe) mode. The computer still crashed multiple times over a few hours. I'm attaching the minidumps from those crashes. Does it still look like NVSTOR.SYS and/or NVSTOR64.SYS are causing the crashes?
- Just a reminder, I ran memtest for 6 successful passes a few days ago.

Any other suggestions? I'm thinking about formatting and starting with a fresh install of Windows 7 and possible using the 32-bit version rather than the 64-bit version to see if that will help straighten things out.

Thank you for your help.

-Scott

zigzag3143 · 20 Nov 2010

euckersw said:

I have confirmed that I am running the latest versions of NVSTOR.SYS and NVSTOR64.SYS.

Here are a few more updates/things I've tried:

- Yesterday I ran the computer for over 24 hours in safe mode without a BSOD.
- This morning I unplugged my NVIDIA video card and my DVD-ROM (which is also using a SATA connection). Therefore I was using the original on-board video card. I then booted up into regular (non-safe) mode. The computer still crashed multiple times over a few hours. I'm attaching the minidumps from those crashes. Does it still look like NVSTOR.SYS and/or NVSTOR64.SYS are causing the crashes?
- Just a reminder, I ran memtest for 6 successful passes a few days ago.

Any other suggestions? I'm thinking about formatting and starting with a fresh install of Windows 7 and possible using the 32-bit version rather than the 64-bit version to see if that will help straighten things out.

Thank you for your help.

-Scott

Still memory corruption being blamed. Suspect a driver perhaps your storage driver. ONly way to tell is to run driver verifier

Beyond that, please run Verifier with these settings:

Using Driver Verifier is an iffy proposition. Most times it'll crash and it'll tell you what the driver is. But sometimes it'll crash and won't tell you the driver. Other times it'll crash before you can log in to Windows. If you can't get to Safe Mode, then you'll have to resort to offline editing of the registry to disable Driver Verifier.

So, I'd suggest that you first backup your stuff and then make sure you've got access to another computer so you can contact us if problems arise. Then make a System Restore point (so you can restore the system using the Vista/Win7 Startup Repair feature).

Then, here's the procedure:
- Go to Start and type in "verifier" (without the quotes) and press Enter
- Select "Create custom settings (for code developers)" and click "Next"
- Select "Select individual settings from a full list" and click "Next"
- Select everything EXCEPT FOR "Low Resource Simulation" and click "Next"
NOTE: You can use Low Resource Simulation if you'd like. From my limited experimentation it makes the BSOD's come faster.
- Select "Select driver names from a list" and click "Next"
Then select all drivers NOT provided by Microsoft and click "Next"
- Select "Finish" on the next page.

Reboot the system and wait for it to crash to the Blue Screen. Continue to use your system normally, and if you know what causes the crash, do that repeatedly. The objective here is to get the system to crash because Driver Verifier is stressing the drivers out. If it doesn't crash for you, then let it run for at least 36 hours of continuous operation (an estimate on my part).

Reboot into Windows (after the crash) and turn off Driver Verifier by going back in and selecting "Delete existing settings" on the first page, then locate and zip up the memory dump file and upload it with your next post.

If you can't get into Windows because it crashes too soon, try it in Safe Mode.
If you can't get into Safe Mode, try using System Restore from your installation DVD to set the system back to the previous restore point that you created.

If that doesn't work, post back and we'll have to see about fixing the registry entry off-line:

Code:

Delete these registry keys (works in XP, Vista, Win7):
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel

Using Driver Verifier to identify issues with Windows drivers for advanced users

Code:

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\K\Desktop\New folder\112010-19515-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;srv*e:\symbols
*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`03062000 PsLoadedModuleList = 0xfffff800`0329fe50
Debug session time: Sat Nov 20 11:10:24.590 2010 (GMT-5)
System Uptime: 0 days 0:19:41.056
Loading Kernel Symbols
.

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..............................................................
................................................................
...........
Loading User Symbols
Loading unloaded module list
......
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {fffff6ec40017a18, 2, 1, fffff800030eac84}

Probably caused by : memory_corruption ( nt!MiPfnShareCountIsZero+104 )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff6ec40017a18, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff800030eac84, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff8000330a0e0
 fffff6ec40017a18 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiPfnShareCountIsZero+104
fffff800`030eac84 4c890410        mov     qword ptr [rax+rdx],r8

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  svchost.exe

TRAP_FRAME:  fffff88004ea7770 -- (.trap 0xfffff88004ea7770)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000006c40017a18 rbx=0000000000000000 rcx=0000000000000045
rdx=fffff68000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030eac84 rsp=fffff88004ea7900 rbp=0000058000000000
 r8=00000000d49f9963  r9=0000000000000005 r10=ffffd88002f439f0
r11=0000007ffffffff8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
nt!MiPfnShareCountIsZero+0x104:
fffff800`030eac84 4c890410        mov     qword ptr [rax+rdx],r8 ds:fffff6ec`40017a18=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800030d1ca9 to fffff800030d2740

STACK_TEXT:  
fffff880`04ea7628 fffff800`030d1ca9 : 00000000`0000000a fffff6ec`40017a18 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`04ea7630 fffff800`030d0920 : 00000000`00000000 fffffa80`03445bc0 00000000`000007ff 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`04ea7770 fffff800`030eac84 : fffffa80`0344e980 fffff800`030f8b83 ffffffff`ffffffff fffff800`031d8c76 : nt!KiPageFault+0x260
fffff880`04ea7900 fffff800`03117db5 : 00000003`00000000 00000000`00000000 fffffa80`03c6a060 81d00001`16c94225 : nt!MiPfnShareCountIsZero+0x104
fffff880`04ea7970 fffff800`030ece2b : 00000000`77163004 fffff680`003b8b18 00000000`00000000 fffff800`00000000 : nt!MiCopyOnWrite+0x7a5
fffff880`04ea7ac0 fffff800`030d082e : 00000000`00000001 00000000`77030000 00000000`00000001 00000000`00000000 : nt!MmAccessFault+0xa2b
fffff880`04ea7c20 00000000`77078f69 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x16e
00000000`000ef7f0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77078f69


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiPfnShareCountIsZero+104
fffff800`030eac84 4c890410        mov     qword ptr [rax+rdx],r8

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nt!MiPfnShareCountIsZero+104

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c44a9

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0xA_nt!MiPfnShareCountIsZero+104

BUCKET_ID:  X64_0xA_nt!MiPfnShareCountIsZero+104

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffff6ec40017a18, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff800030eac84, address which referenced memory

Debugging Details:
------------------


WRITE_ADDRESS:  fffff6ec40017a18 

CURRENT_IRQL:  2

FAULTING_IP: 
nt!MiPfnShareCountIsZero+104
fffff800`030eac84 4c890410        mov     qword ptr [rax+rdx],r8

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  svchost.exe

TRAP_FRAME:  fffff88004ea7770 -- (.trap 0xfffff88004ea7770)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000006c40017a18 rbx=0000000000000000 rcx=0000000000000045
rdx=fffff68000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030eac84 rsp=fffff88004ea7900 rbp=0000058000000000
 r8=00000000d49f9963  r9=0000000000000005 r10=ffffd88002f439f0
r11=0000007ffffffff8 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
nt!MiPfnShareCountIsZero+0x104:
fffff800`030eac84 4c890410        mov     qword ptr [rax+rdx],r8 ds:fffff6ec`40017a18=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff800030d1ca9 to fffff800030d2740

STACK_TEXT:  
fffff880`04ea7628 fffff800`030d1ca9 : 00000000`0000000a fffff6ec`40017a18 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`04ea7630 fffff800`030d0920 : 00000000`00000000 fffffa80`03445bc0 00000000`000007ff 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`04ea7770 fffff800`030eac84 : fffffa80`0344e980 fffff800`030f8b83 ffffffff`ffffffff fffff800`031d8c76 : nt!KiPageFault+0x260
fffff880`04ea7900 fffff800`03117db5 : 00000003`00000000 00000000`00000000 fffffa80`03c6a060 81d00001`16c94225 : nt!MiPfnShareCountIsZero+0x104
fffff880`04ea7970 fffff800`030ece2b : 00000000`77163004 fffff680`003b8b18 00000000`00000000 fffff800`00000000 : nt!MiCopyOnWrite+0x7a5
fffff880`04ea7ac0 fffff800`030d082e : 00000000`00000001 00000000`77030000 00000000`00000001 00000000`00000000 : nt!MmAccessFault+0xa2b
fffff880`04ea7c20 00000000`77078f69 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x16e
00000000`000ef7f0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77078f69


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiPfnShareCountIsZero+104
fffff800`030eac84 4c890410        mov     qword ptr [rax+rdx],r8

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  nt!MiPfnShareCountIsZero+104

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4c1c44a9

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0xA_nt!MiPfnShareCountIsZero+104

BUCKET_ID:  X64_0xA_nt!MiPfnShareCountIsZero+104

Followup: MachineOwner
---------

euckersw · 20 Nov 2010

Zigzag,

Thank you for the response. I did run Drive Verifier a few days ago, and posted my mini dumps on the first page of this thread. Is that all of the information that you need? As you'll see on the first page, the actual full sized error dump was huge (~300 MBs), so I did not post those.

-Scott

CarlTR6 · 21 Nov 2010

Scott, you have made changes to your system since you first ran Driver Verifier. You have updated or eliminated some out of date drivers. Therefore, I agree with ZigZag; it is time to try Driver Verifier again. The fact that you can run in the Safe Mode with out a crash indicates that the basic files and drivers necessary for your system to run are fine. They are not causing the problem. Something loading in a normal boot is creating a problem.

Here something else you can try to search for the problem. How to perform a clean boot in Windows 7: How to troubleshoot a problem by performing a clean boot in Windows Vista or in Windows 7

euckersw · 21 Nov 2010

Carl,

Great - make sense. I'm playing around with the Clean Boot options now (I didn't know that even existed, so thank you for the suggestion). If that doesn't lead me to any conclusions, I'll run Driver Verifier again and post the results (including the full error log, which I'll post on RapidShare or something similar). Either way I'll share what I find. Thanks again for your help.

-Scott

CarlTR6 · 21 Nov 2010

You are welcome, Scott. I hope clean booting will reveal the problem. I have used this technique on my own system and found the problem.

euckersw · 30 Nov 2010

As an update, it's looking like it's a memory hardware issue. Since I last checked in I've updated my system with a fresh install of Windows 7 64-bit, tried a fresh install of Windows 7 32-bit, and swapped out the power supply - all to no avail. Then I pulled out 2 of my 4 DDR2 DIMMs, and now the computer has been running without a BSOD for about 2 days. I'm happy that I think I've found the problem, but what's really annoying is that Memtest86+ came back with 6 clean passes (no errors) on my RAM. Is this possible and/or is there a reason why Memtest86+ wouldn't have found an issue that might be there?

Thanks again for the help from this forum.

-Scott

CarlTR6 · 30 Nov 2010

Scott, we recommend a minimum of seven passes with Memtest. I have seen errors not show up until the 12th or 13th passes. And Memtest is not perfect; we have seen faulty RAM never detected with Memtest. If Memtest does not show any errors, we generally advise running it again from a cold boot after the computer has been off for a while. Next, we advise running Prime95 and using a blended test which tests both the RAM and the CPU. However, you now know you have a RAM problem. It could be a bad stick, a bad motherboard slot, incompatible RAM, or even a bad memory controller.

Thank you for the update - and you are very welcome for the help. That is why we are here. :)