[SOLVED] Win7 reinstall still getting BOSD - 0x101 - CLOCK_WATCHDOG_TIMEOUT

W

Warren

Member
Joined
Feb 7, 2014
Posts
16
Hi I've been getting random BSOD and mouse freezing on my system which is 3 yrs old and haven't been able to fix it despite driver updates. I thought it could be Firefox 25.0 causing the problem so I stopped using it and went to Chrome. The system seemed more stable but I got the mouse freezing and BSOD eventually. I decided to do a fresh install of Win 7 to fix the problems. 3 days into the new install I got a BSOD. I have the new install on a separate drive attached with SATA dock at the top of my case which has a SATA cable to the MB and the old drive is still connected till I get everything working well. I boot into either system with the boot options on my bios.

· OS - Windows 7 Pro
· x64
· What was original installed OS on system? Windows 7 Pro
· OEM version (came pre-installed on system)
· 3 years old
· 3 year old install and 3 day old install another drive (BSOD report is from the new 3 day old install)

· Intel i7-950 3.06 GHz not overclocked
· Video Card EVGA NVIDA GeForce GTX 460 EE(AR) 675 MHz
· MotherBoard Gigabyte Technology Co., Ltd. X58A-UD3R ver 2.0
· Power Supply - Corsair 850HX

· AVA Direct
· Custom Build

· Desktop

Thanks in advance for any help you can give me.
WarrenView attachment Warren.zip


 
Hi,

The attached DMP file is of the CLOCK_WATCHDOG_TIMEOUT (101) bug check.

This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

Unfortunately, we need a kernel-dump to analyze this type of bug check as a minidump does not contain enough information at the time of the crash.

-- Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > Change from Minidump to Kernel Dump, Apply, OK.

After that, please go ahead and enable Driver Verifier for the maximum information possible:

Driver Verifier:

What is Driver Verifier?

Driver Verifier is included in Windows 8, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.

Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8 - Restore Point - Create in Windows 8

How to enable Driver Verifier:

Start > type "verifier" without the quotes > Select the following options -

1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

- If Driver Verifier finds a violation, the system will BSOD.

- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > Search > type "cmd" without the quotes.

- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.

If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > type "system restore" without the quotes.

- Choose the restore point you created earlier.

How long should I keep Driver Verifier enabled for?

It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier.

My system BSOD'd, where can I find the crash dumps?

They will be located in %systemroot%\Minidump

Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users

Regards,

Patrick
 
Thanks for the quick reply. I checked the settings and it already says kernel dump. I try the driver verifier.
Warren

Patrick said:
Hi,

The attached DMP file is of the CLOCK_WATCHDOG_TIMEOUT (101) bug check.

This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

Unfortunately, we need a kernel-dump to analyze this type of bug check as a minidump does not contain enough information at the time of the crash.

-- Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > Change from Minidump to Kernel Dump, Apply, OK.

After that, please go ahead and enable Driver Verifier for the maximum information possible:

Driver Verifier:

What is Driver Verifier?

Driver Verifier is included in Windows 8, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.

Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.

Before enabling Driver Verifier, it is recommended to create a System Restore Point:

Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8 - Restore Point - Create in Windows 8

How to enable Driver Verifier:

Start > type "verifier" without the quotes > Select the following options -

1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.

Important information regarding Driver Verifier:

- If Driver Verifier finds a violation, the system will BSOD.

- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.

If this happens, do not panic, do the following:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > Search > type "cmd" without the quotes.

- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.

If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:

- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.

- Once in Safe Mode - Start > type "system restore" without the quotes.

- Choose the restore point you created earlier.

How long should I keep Driver Verifier enabled for?

It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier.

My system BSOD'd, where can I find the crash dumps?

They will be located in %systemroot%\Minidump

Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users

Regards,

Patrick
Click to expand...
 
Great, when you crash again, the dump file will be generated at the following path > C:\Windows, and labeled MEMORY.DMP.

You'll have to upload it to a 3rd party hosting website such as Mediafire, Skydrive, Google Drive, etc, as it'll be too large to attach here.

Regards,

Patrick
 
Great, thanks.

So, as I said above, the attached DMP file is of the CLOCK_WATCHDOG_TIMEOUT (101) bug check.

This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

BugCheck 101, {19, 0, fffff88003088180, 5}

19 clock ticks in regards to the timeout.

fffff88003088180 is the PRCB address of the hung processor, let's keep this address in mind.

Code: 
0: kd> !prcb 5
PRCB for Processor 5 at [COLOR=#ff0000][I][B]fffff88003088180[/B][/I][/COLOR]:
Current IRQL -- 0
Threads--  Current fffff880030930c0 Next 0000000000000000 Idle fffff880030930c0
Processor Index 5 Number (0, 5) GroupSetMember 20
Interrupt Count -- 000537a0
Times -- Dpc    00000153 Interrupt 000000c2 
         Kernel 000125c5 User      00000005

For reference, I did not do !prcb 0 through 5. That would have been very tedious. Instead, you can run the !running -it command. The "i" argument causes it to display idle procs too, and "t" displays the stack trace for the thread running on each proc.

Hint: At times, the 4th parameter of the bugcheck will show you the responsible processor. For example, in your *101 here, it was correct as the 4th parameter was 5.

As this matches the 3rd parameter of the bugcheck, processor #5 is the responsible processor. Now with the information we have here thus far, we know that processor #5 reached 19 clock ticks without responding, therefore the system 'd. Before we go further, what is a clock tick? A clock interrupt is a form of interrupt which involves counting the the cycles of the processor core, which is running a clock on the processors to keep them all in sync. A clock interrupt is handed out to all processors and then they must report in, and when one doesn't report in, you then crash.

----------

If we go ahead and switch to processor #5 to see what's going on in the call stack:

Code: 
5: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`030b0148 fffff800`02e12245 : fffff880`030b0160 00000000`00000000 00000000`00000002 fffff800`00000000 : hal!HalpPciReadMmConfigUlong+0x7
fffff880`030b0150 fffff800`02e12b32 : 00000000`f030001b fffff880`030b02b0 00000000`00000040 00000000`00000000 : hal!HalpPCIPerformConfigAccess+0x55
fffff880`030b0180 fffff800`02e1202c : 00000000`00000002 fffff800`00000000 fffff880`030b0380 00000000`00000040 : hal!HalpPciAccessMmConfigSpace+0x196
fffff880`030b01d0 fffff800`02e11e06 : 00000000`00000040 ffffffff`00000000 00000000`00000000 fffff880`030b0380 : hal!HalpPCIConfig+0x9c
fffff880`030b0240 fffff800`02e11986 : 00000000`00000000 fffffa80`00000000 00000000`00000000 00000000`00000040 : hal!HalpReadPCIConfig+0x5e
fffff880`030b0280 fffff800`02e12c12 : 00000000`00000001 fffff880`030b03b0 00000000`00012612 00000000`00000002 : hal!HalpGetPCIData+0x8e
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for nvlddmkm.sys - 
fffff880`030b0350 fffff880`0f287c30 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`0050a614 : hal!HalGetBusDataByOffset+0x86
fffff880`030b0440 fffff880`0f2c40e2 : fffffa80`0b2fe000 fffffa80`0b8cb920 fffffa80`0b8cb920 00000000`0050a614 : nvlddmkm+0x1cec30
fffff880`030b0480 fffff880`0f25653a : fffffa80`0b2f5000 fffffa80`0b8cb920 fffffa80`0b2f5000 00000000`ffffffff : nvlddmkm+0x20b0e2
fffff880`030b04e0 fffff880`0f28366a : fffffa80`0b2f5000 fffffa80`0b2f5000 fffffa80`0b8cb920 fffffa80`0b8cb920 : nvlddmkm+0x19d53a
fffff880`030b0550 fffff880`0f2d21cf : fffffa80`0b2f5000 fffffa80`0b2f55c8 00000000`0050a614 fffff880`0f2d21cf : nvlddmkm+0x1ca66a
fffff880`030b0580 fffff880`0f4232de : 00000000`ffffffff 00000000`0050a614 00000000`00000a20 fffffa80`0b2f5000 : nvlddmkm+0x2191cf
fffff880`030b05e0 fffff880`0f51fc31 : 00000000`00001000 fffffa80`097629b0 fffffa80`09754e30 c0000000`0007ff3f : nvlddmkm+0x36a2de
fffff880`030b0630 fffff880`0fb598c4 : fffffa80`0b2f5000 fffffa80`0974ccc0 fffffa80`097629b0 fffffa80`ffe005f0 : nvlddmkm+0x466c31
fffff880`030b0670 fffff880`0f348a9f : fffffa80`0b300000 fffffa80`0b2f55c8 00000000`00000000 00000000`00000010 : nvlddmkm!nvDumpConfig+0x42b68c
fffff880`030b0710 fffff880`0f3c2ef5 : fffffa80`0b300000 fffffa80`0974ccc0 fffffa80`0b2f5000 00000000`00000010 : nvlddmkm+0x28fa9f
fffff880`030b0740 fffff880`0f42d74a : fffffa80`0b2f5000 fffffa80`0b30e000 fffffa80`0b300000 00000000`000057d4 : nvlddmkm+0x309ef5
fffff880`030b07a0 fffff880`0f436f3f : 00000000`00000010 00000000`00000000 fffffa80`0b2ff460 fffff880`030b08c0 : nvlddmkm+0x37474a
fffff880`030b0800 fffff880`0f350e55 : 00000000`00000000 00000000`00000000 fffffa80`0b2ff460 fffffa80`0b344f90 : nvlddmkm+0x37df3f
fffff880`030b0840 fffff880`0f351409 : fffffa80`0b2ff460 fffff880`030b0910 00000000`00000040 00000000`00000040 : nvlddmkm+0x297e55
fffff880`030b0890 fffff880`0f42e9dd : 00000000`00000040 fffffa80`0b2f5000 fffffa80`0b2f5000 fffffa80`0b2ff460 : nvlddmkm+0x298409
fffff880`030b0920 fffff880`0f404191 : fffffa80`0b2f5000 00000000`00000013 00000000`00000001 00000000`00000000 : nvlddmkm+0x3759dd
fffff880`030b0960 fffff880`0f403c30 : fffffa80`0b300000 00000000`00000013 00000000`00000006 fffffa80`0b2f5000 : nvlddmkm+0x34b191
fffff880`030b0990 fffff880`0f403e24 : fffffa80`0d0a37b0 00000000`00000014 00000000`00080000 fffffa80`0b37a760 : nvlddmkm+0x34ac30
fffff880`030b09e0 fffff880`0f40487e : 00000000`00000000 00000000`00080000 fffffa80`0b2f5000 fffff880`0f2a3f9f : nvlddmkm+0x34ae24
fffff880`030b0a20 fffff880`0f5234df : fffffa80`0b2f5000 fffff880`030b0b39 fffffa80`0b2f5410 fffffa80`0b8cb920 : nvlddmkm+0x34b87e
fffff880`030b0a50 fffff880`0f259ad4 : 00000000`00000000 fffff880`030b0b39 fffffa80`0b2f5410 00000000`00000000 : nvlddmkm+0x46a4df
fffff880`030b0a80 fffff880`0f180a0a : fffffa80`0b9bb000 00000000`00000000 fffffa80`0b9bb0d0 00000000`00000000 : nvlddmkm+0x1a0ad4
fffff880`030b0ba0 fffff880`0f1dec9f : fffff880`0f18098b fffffa80`0b9bb000 fffffa80`0b9bb000 00000000`00000000 : nvlddmkm+0xc7a0a
fffff880`030b0c40 fffff800`02eccd0c : fffff880`0f1dec26 fffff880`03088180 00000000`d11aa8cd 00000000`0000005d : nvlddmkm+0x125c9f
fffff880`030b0cd0 fffff800`02eba24a : fffff880`03088180 fffff880`030930c0 00000000`00000000 fffff880`0f1df638 : nt!KiRetireDpcList+0x1bc
fffff880`030b0d80 00000000`00000000 : fffff880`030b1000 fffff880`030ab000 fffff880`030b0d40 00000000`00000000 : nt!KiIdleLoop+0x5a

1. It starts with a KiIdleLoop routine, which is essentially the start of the System Idle Process you see in Task Manager. This indicates this process was waiting to do something.

2. We then get to the KiRetireDpcList - Function that will sit in a loop dequeing DPCs from the current processor’s DPC queue and calling the callbacks. I will explain DPC's below.

What is a DPC? That is a Deferred Procedure Call, which is a Microsoft Windows operating system mechanism which allows high-priority tasks (e.g. an interrupt handler) to defer required but lower-priority tasks for later execution. This permits device drivers and other low-level event consumers to perform the high-priority part of their processing quickly, and schedule non-critical additional processing for execution at a lower priority.

DPCs are implemented by DPC objects which are created and initialized by the kernel when a device driver or some other kernel mode program issues requests for DPC. The DPC request is then added to the end of a DPC queue. Each processor has a separate DPC queue. DPCs have three priority levels: low, medium and high. By default, all DPCs are set to medium priority. When Windows drops to an IRQL of Dispatch/DPC level, it checks the DPC queue for any pending DPCs and executes them until the queue is empty or some other interrupt with a higher IRQL occurs.

For example, when the clock interrupt is generated, the clock interrupt handler generally increments the counter of the current thread to calculate the total execution time of that thread, and decrements its quantum time remaining by 1. When the counter drops to zero, the thread scheduler has to be invoked to choose the next thread to be executed on that processor and dispatcher to perform a context switch. Since the clock interrupt occurs at a much higher IRQL, it will be desirable to perform this thread dispatching which is a less critical task at a later time when the processor's IRQL drops. So the clock interrupt handler requests a DPC object and adds it to the end of the DPC queue which will process the dispatching when the processor's IRQL drops to DPC/Dispatch level.

3. After this, we get tons and tons of nvlddmkm.sys calls which is the nVidia video driver.

4. We then have various hal.dll (Hardware Abstraction Layer) routines.

- The HalGetBusData routine is obsolete and is exported only to support existing drivers.

- HalpGetPCIData ???

- HalpReadPCIConfig ???

- HalpPciAccessMmConfigSpace ???

- HalpPCIPerformConfigAccess ???

- HalpPciReadMmConfigUlong ???

--------------

Overall, it appears we're dealing with a video card driver issue and/or video card issue itself.

Ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.

Regards,

Patrick
 
Patrick, have you checked the Interrupt Flag? The r command should work:

Code: 
r@ if

The bit setting within this FLAGS register will determine if a CPU is able to handle hardware interrupts. It uses BOOLEAN values, so 1 being true and 0 being false.
 
x BlueRobot said:
Patrick, have you checked the Interrupt Flag? The r command should work:

Code: 
r@ if

The bit setting within this FLAGS register will determine if a CPU is able to handle hardware interrupts. It uses BOOLEAN values, so 1 being true and 0 being false.
Click to expand...

I was just about to, but it appears the OP deleted the kernel from Dropbox (likely for security purposes).
 
The attached DMP file is of the DRIVER_VERIFIER_DETECTED_VIOLATION (c4) bug check.

This is the general bug check code for fatal errors found by Driver Verifier.

-- Thanks to Harry for *C4 debugging tips!

BugCheck C4, {f6, 1d4, fffffa800d14b6a0, fffff8800f129295}

2nd parameter of the bug check = Value of the handle being referenced.

3rd parameter of the bug check = Current process address.

Code: 
4: kd> !process fffffa800d14b6a0
PROCESS fffffa800d14b6a0
    SessionId: 1  Cid: 0894    Peb: 7fffffda000  ParentCid: 03d8
    DirBase: 1e7f46000  ObjectTable: fffff8a002958a30  [COLOR=#ff0000][I][B]HandleCount: 117[/B][/I][/COLOR].
    [COLOR=#ff0000][I][B]Image: nvspcaps64.exe[/B][/I][/COLOR]
    VadRoot fffffa800d14b5b0 Vads 111 Clone 0 Private 1171. Modified 1638. Locked 0.
    DeviceMap fffff8a00254f8c0
    Token                             fffff8a002995060
    ElapsedTime                       00:00:00.436
    UserTime                          00:00:00.000
    KernelTime                        00:00:00.000
    QuotaPoolUsage[PagedPool]         202952
    QuotaPoolUsage[NonPagedPool]      13328
    Working Set Sizes (now,min,max)  (2705, 50, 345) (10820KB, 200KB, 1380KB)
    PeakWorkingSetSize                2705
    VirtualSize                       107 Mb
    PeakVirtualSize                   107 Mb
    PageFaultCount                    2816
    MemoryPriority                    BACKGROUND
    BasePriority                      8
    CommitCharge                      1628

The process is nvspcaps64.exe (NVIDIA Capture Server) and its current holding handle count is 117.

If we run !handle on the value:

Code: 
4: kd> !handle 1d4

PROCESS fffffa800d14b6a0
    SessionId: 1  Cid: 0894    Peb: 7fffffda000  ParentCid: 03d8
    DirBase: 1e7f46000  ObjectTable: fffff8a002958a30  HandleCount: 117.
    [COLOR=#ff0000][I][B]Image: nvspcaps64.exe[/B][/I][/COLOR]

Handle table at fffff8a002958a30 with 117 entries in use

01d4: Object: fffff8a00299f570  GrantedAccess: 00020006 Entry: fffff8a00299e750
Object: fffff8a00299f570  Type: (fffffa80097b0f30) Key
    ObjectHeader: fffff8a00299f540 (new version)
        HandleCount: 1  PointerCount: 1
        Directory Object: 00000000  Name: \REGISTRY\MACHINE\SYSTEM\CONTROLSET001\CONTROL\CLASS\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\[COLOR=#ff0000][I][B]NVSPCAPS[/B][/I][/COLOR]

It's a registry key, let's take a closer look:

Code: 
4: kd> !reg findkcb \REGISTRY\MACHINE\SYSTEM\CONTROLSET001\CONTROL\CLASS\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\NVSPCAPS


Found KCB = [COLOR=#ff0000][I][B]fffff8a003193380 [/B][/I][/COLOR]:: \REGISTRY\MACHINE\SYSTEM\CONTROLSET001\CONTROL\CLASS\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\NVSPCAPS

Now that we have the Key Control Block address, let's go further:

Code: 
4: kd> !reg kcb fffff8a003193380

Key              : \REGISTRY\MACHINE\SYSTEM\CONTROLSET001\CONTROL\CLASS\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\NVSPCAPS
[COLOR=#ff0000][I][B]RefCount         : 1[/B][/I][/COLOR]
Flags            : CompressedName,
ExtFlags         :
Parent           : 0xfffff8a00a3dbb98
KeyHive          : 0xfffff8a000022300
KeyCell          : 0xb1d6f8 [cell index]
[COLOR=#ff0000][I][B]TotalLevels      : 9[/B][/I][/COLOR]
MaxNameLen       : 0x0
MaxValueNameLen  : 0x0
MaxValueDataLen  : 0x0
LastWriteTime    : 0x 1cf24ee:0xd15b9510
KeyBodyListHead  : 0xfffff8a0031933f8 0xfffff8a0031933f8
SubKeyCount      : 0
ValueCache.Count : 0
Owner            : 0x0000000000000000
KCBLock          : 0xfffff8a003193470
KeyLock          : 0xfffff8a003193480

The reference count is 1, therefore only one process has an handle open to that registry key. The Flags indicates the name of the key is in a compressed form, and the registry key is current 9 levels deep into the registry. \REGISTRY\MACHINE\SYSTEM would be 3 levels.

----------

As far as I know, this is a bug with Driver Verifier. The issue occurs because of an error in the Stream.sys component. When Driver Verifier is enabled, every kernel mode reference to a user mode handle receives security validation. The computer crashes if this security validation does not occur in the context of a process that is not under the LocalSystem account. Therefore, in certain situations when the Stream.sys component references user-mode handles in kernel mode and Driver Verifier is enabled, this issue occurs.

To be sure, please try installing this hotfix and then keep verifier enabled - "0x000000C4" Stop error when you enable Driver Verifier in Windows 7 or in Windows Server 2008 R2

Regards,

Patrick
 
I ran the hot fix and then started driver verifier. The system crashed on reboot and no dump was made despite the BSOD saying otherwise. So I booted into safe mode and turned off driver verifier and restarted windows. I restarted driver verifiier and rebooted. The system crashed immediately and still gives the C4 error and nvlddmkm.sys errors. Here is the new memory dump.
https://www.dropbox.com/s/zk7dzhuz92gvm0w/MEMORY after hotfix.DMP
 
Great, thanks. This confirms my suspicion as to whether or not we were dealing with a DV bug or as I now see it perhaps a faulty video card. The reason I am mentioning a faulty card video is because:

1. In the *101 DMP, as I mentioned, we have tons and tons of nVidia video driver calls one after the other.

2. We then eventually as I mentioned hit various Hardware Abstraction Layer and PCI Configuration Space related routines (strictly hardware, really).

3. The latest post-hotfix bug check is the same as above, faulting the nVidia video driver.

Go ahead and disable DV since we'll just keep getting a *C4 nVidia video driver loop over & over again now. Until you crash again and can attach a new *101, please do the following:

- If you have access to a secondary video card, or integrated graphics, please uninstall your video card drivers, shut down, physically remove video card, install secondary card or enable integrated graphics, boot to Windows and install latest video card drivers, monitor the system.

- If the above fails, run Memtest for NO LESS than ~8 passes (several hours):

Memtest86+:

Download Memtest86+ here:

Memtest86+ - Advanced Memory Diagnostic Tool

Which should I download?

You can either download the pre-compiled ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).

How Memtest works:

Memtest86 writes a series of test patterns to most memory addresses, reads back the data written, and compares it for errors.

The default pass does 9 different tests, varying in access patterns and test data. A tenth test, bit fade, is selectable from the menu. It writes all memory with zeroes, then sleeps for 90 minutes before checking to see if bits have changed (perhaps because of refresh problems). This is repeated with all ones for a total time of 3 hours per pass.

Many chipsets can report RAM speeds and timings via SPD (Serial Presence Detect) or EPP (Enhanced Performance Profiles), and some even support changing the expected memory speed. If the expected memory speed is overclocked, Memtest86 can test that memory performance is error-free with these faster settings.

Some hardware is able to report the "PAT status" (PAT: enabled or PAT: disabled). This is a reference to Intel Performance acceleration technology; there may be BIOS settings which affect this aspect of memory timing.

This information, if available to the program, can be displayed via a menu option.

Any other questions, they can most likely be answered by reading this great guide here:

FAQ : please read before posting

Regards,

Patrick
 
I don't think so, there likely won't be any drivers for it. If you have integrated video, that would be a much better option just based on the fact there would be drivers.

Regards,

Patrick
 
I just pulled it out it's a AIW X800XL PCIe card, I found legacy Vista 64 bit drivers for it, will that work? No integrated video
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top