X58A-UD3R rev 2.0 Win7 BSOD i7 950 no overclock

G

Gigabyte_hell

Member
Joined
Nov 19, 2013
Posts
8
System won't POST without either DEFAULT or OPTIMIZED BIOS settings--no overclocks. PSU is a Corsair 850W.

Can run Prime95 for 45 minutes, no problems. Ran 2 full passes of memtest on RAM. Ran Furmark on GPU for 2 hours. None of that triggered BSOD.

Ran CHDSK on all drives. Ran both Seagate and WD utilities to check drive function. Had one drive showing errors--zeroed it and now it passes.

Thought it might be Realtek NIC so I disabled it and added an INTEL PRO 1000/GT. Just BSOD'd on me again, so that's not it.

Thought it was Firefox (usually happens web-surfing) so switched to Chrome. No dice. Last crash had Chrome, Truecrypt and Lightroom actively in use. I suppose Steam and Origin were sitting there in the background.

I can't spot the pattern. I thought I'd enabled drive verifier, but every time I query it it tells me its not running...

Could REALLY use some help on this one. Thanks!

SPECS:

· Windows 7 x64
· Clean Install of Technet ISO

· CPU - i7 950
· Video Card - PNY 560ti 1GB (non 448)
· MotherBoard - X58a-ud3r rev 2.0 firmware FH (newest)
· Power Supply - Corsair 850W
 

Attachments

Hi,

All of the attached DMP files are 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.

We however cannot analyze these types of bug checks without a Kernel dump.
Please do the following:

1. Set the type of crash dump to Kernel - Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > ensure there is a check mark next to 'Write an event to the system log' > Ensure 'Automatically restart' is un-checked.


2. Enable Driver Verifier afterwards:

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 > type "system restore" without the quotes.

- Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:

- 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.

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

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

In regards to the perfmon:

[TABLE="class: block"]
[TR]
[TD="class: h4"]Symptom:
[/TD]
[TD="class: info, align: center"]
error.gif

Device is disabled.[/TD]
[/TR]
[TR]
[TD="class: h4, width: 12%"]Cause:[/TD]
[TD="class: info b2, align: center"]A device is disabled preventing it from working properly.[/TD]
[/TR]
[TR]
[TD="class: h4, width: 12%"]Details:[/TD]
[TD="class: info, align: center"]The device, Realtek PCIe GBE Family Controller, is disabled. If this device is no longer used it may be intentionally disabled. The Plug and Play ID for this device is 7.[/TD]
[/TR]
[/TABLE]

Is this on purpose?

Regards,

Patrick
 
Patrick said:
In regards to the perfmon:

[TABLE="class: block"]
[TR]
[TD="class: h4"]Symptom:[/TD]
[TD="class: info, align: center"]
error.gif

Device is disabled.[/TD]
[/TR]
[TR]
[TD="class: h4, width: 12%"]Cause:[/TD]
[TD="class: info b2, align: center"]A device is disabled preventing it from working properly.[/TD]
[/TR]
[TR]
[TD="class: h4, width: 12%"]Details:[/TD]
[TD="class: info, align: center"]The device, Realtek PCIe GBE Family Controller, is disabled. If this device is no longer used it may be intentionally disabled. The Plug and Play ID for this device is 7.[/TD]
[/TR]
[/TABLE]

Is this on purpose?

Regards,

Patrick
Click to expand...

Yes. I nuked it as I had an Intel NIC handy, thinking that would fix things. It didn't. Should I delete it entirely from within hardware management?

I'm performing the steps you've supplied. Will report back.
 
No, it's fine as it is, I was just ensuring this was done purposely.

Keep me updated.

Regards,

Patrick
 
Patrick said:
No, it's fine as it is, I was just ensuring this was done purposely.

Keep me updated.

Regards,

Patrick
Click to expand...

I've attached a number of dumps. 10 point toward ntoskrnl.exe, while 1 points toward an Nvidia display driver...but who am I kidding--I have no idea what I'm looking at. I'll let you tell me what's happening.

I gave you the minidumps, but the "full" dumps (I have two) are 90MB and 150MB. Do you require these? Where should I upload them for you (I don't belong to any file locker sites, etc).

Thanks!
 

Attachments

Minidumps in this case are unfortunately going to do us no good as 101 bug checks require a Kernel or higher to analyze, because minidumps don't hold enough info from the time of crash. With that said, the full dumps are what I am interested in. You'll need to host those offsite because they are too big to attach. You can use something like Mediafire, Skydrive, Dropbox, etc. Whatever you'd like.

Regards,

Patrick
 
Patrick said:
Minidumps in this case are unfortunately going to do us no good as 101 bug checks require a Kernel or higher to analyze, because minidumps don't hold enough info from the time of crash. With that said, the full dumps are what I am interested in. You'll need to host those offsite because they are too big to attach. You can use something like Mediafire, Skydrive, Dropbox, etc. Whatever you'd like.

Regards,

Patrick
Click to expand...

Appreciate it. Put two dumps on Skydrive.

https://skydrive.live.com/redir?resid=54AA365AF26E127C!165&authkey=!AMxk0iAqD1odeGA

https://skydrive.live.com/redir?resid=54AA365AF26E127C!166&authkey=!AP-VU1f7MdqBjqM
 
Okay, this is actually good. We aren't getting *101's with the verifier enabled. I just wanted you to set it to Kernel just in case we'd get *101's so we can get right to analysis. Don't change it back, keep it on Kernel just in case we need it.

Right, so we have two dumps. The first bug check is of the IRQL_NOT_LESS_OR_EQUAL (a) bug check.

This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above.

This bug check is issued if paged memory (or invalid memory) is accessed when the IRQL is too high. The error that generates this bug check usually occurs after the installation of a faulty device driver, system service, or BIOS.

If we take a look at the call stack:
Code: 
0: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`08088548 fffff800`03493169 : 00000000`0000000a fffff980`01384fd8 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`08088550 fffff800`03491de0 : 00000000`00000007 fffffa80`0d521050 00000000`00000000 fffffa80`0d521050 : nt!KiBugCheckDispatch+0x69
fffff880`08088690 fffff800`0355e588 : fffffa80`0d521050 00000000`00000000 fffff980`01384fa0 fffff880`080888c0 : nt!KiPageFault+0x260 (TrapFrame @ fffff880`08088690)
fffff880`08088820 fffff880`04a78289 : 00000000`00000000 fffffa80`0e813880 fffff980`01384fa0 00000000`00000246 : nt!IoEnumerateDeviceObjectList+0x68
fffff880`08088860 fffff880`04a75a9c : 00000000`0000000c fffffa80`0e813880 fffffa80`0e813880 00000000`00000801 : [COLOR=#ff0000][I][B]hcmon[/B][/I][/COLOR]+0x6289
fffff880`080888c0 fffff880`04a76136 : 00000000`00000000 00000000`81012368 fffffa80`0e3e8810 fffffa80`0da72130 : [COLOR=#ff0000][I][B]hcmon[/B][/I][/COLOR]+0x3a9c
fffff880`08088930 fffff800`0393cd26 : fffffa80`0da72130 00000000`00000009 fffffa80`0da72130 fffffa80`0da72130 : [COLOR=#ff0000][I][B]hcmon[/B][/I][/COLOR]+0x4136
fffff880`080889b0 fffff800`037b03a7 : fffffa80`0e6aa340 fffff880`08088ca0 fffffa80`0e6aa340 fffffa80`0da95010 : nt!IovCallDriver+0x566
fffff880`08088a10 fffff800`037b0c06 : 00000000`00000001 00000000`00000160 00000000`00000000 00000001`3f4fac40 : nt!IopXxxControlFile+0x607
fffff880`08088b40 fffff800`03492e53 : fffffa80`0e73e060 fffff880`08088ca0 fffff880`746c6644 fffff880`08088c38 : nt!NtDeviceIoControlFile+0x56
fffff880`08088bb0 00000000`7728132a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`08088c20)
00000000`0161f2e8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7728132a

We can see that the driver hcmon.sys (VMware USB monitor) was called three times, and right after we have a IoEnumerateDeviceObjectList routine call which enumerates a driver's device object list. This likely explains as to why we see it being called three times. Right after we have the pagefault and then the bug check itself.

It's a verifier enabled dump - FAILURE_BUCKET_ID: X64_0xA_VRF_hcmon+6289

VRF determines that, and the bolded in red right after that if we look at the call stack is one of our hcmon calls (the last one).

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

Check for any VMware updates - VMware Support & Downloads for Desktop, Application & Data Center Virtualization | United States

If there aren't any, I'd suggest removing the software entirely for temporary troubleshooting purposes.

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


Moving on, the next bug check is of the DRIVER_VERIFIER_DETECTED_VIOLATION (c4) bug check.

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

If we look at the call stack:
Code: 
4: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`0bc4eb78 fffff800`0391c4ec : 00000000`000000c4 00000000`000000f6 00000000`000001b0 fffffa80`0a5d0b30 : nt!KeBugCheckEx
fffff880`0bc4eb80 fffff800`03931bf4 : 00000000`000001b0 fffffa80`0a5d0b30 00000000`00000004 00000000`00000000 : nt!VerifierBugCheckIfAppropriate+0x3c
fffff880`0bc4ebc0 fffff800`036e9890 : 00000000`0000000d fffff880`0bc4ee10 fffff880`0bc4ef00 fffff880`0bc4f0c8 : nt![COLOR=#ff0000][I][B]VfCheckUserHandle[/B][/I][/COLOR]+0x1b4
fffff880`0bc4eca0 fffff800`037431a5 : fffff8a0`0146da00 00000000`00000002 fffffa80`0973d420 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x2027e
fffff880`0bc4ed70 fffff800`0348ee53 : 00000000`000001b0 00000000`00000240 00000000`00000000 00000000`00000003 : nt!NtSetValueKey+0xe1
fffff880`0bc4eea0 fffff800`0348b410 : fffff800`039204db fffff880`04d595d1 fffff880`0bc4fafc 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0bc4ef10)
fffff880`0bc4f0a8 fffff800`039204db : fffff880`04d595d1 fffff880`0bc4fafc 00000000`00000000 fffff800`0348b410 : nt!KiServiceLinkage
fffff880`0bc4f0b0 fffff880`04d595d1 : 00000000`00000008 fffff880`0bc4f171 00000000`00000013 ffffffff`80000f80 : nt![COLOR=#ff0000][I][B]VfZwSetValueKey[/B][/I][/COLOR]+0x6b
fffff880`0bc4f100 fffff880`04d59129 : 00000000`00000004 fffff880`0bc4fafc 00000000`00000004 00000000`00000004 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0x995d1
fffff880`0bc4f1c0 fffff880`04da0f87 : fffff880`04d59098 fffff880`0bc4f9c0 fffff880`0bc4f400 fffff880`0bc4f9f8 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0x99129
fffff880`0bc4f260 fffff880`04d7124f : fffff880`0bc4f3c0 00000000`00074e53 00000000`80000000 fffffa80`0a5eb060 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xe0f87
fffff880`0bc4f2b0 fffff880`04d64c00 : fffff880`0bc4f6c8 fffff880`0bc4f380 fffff880`0bc4f400 fffff800`0349c1f8 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xb124f
fffff880`0bc4f300 fffff880`0553bb8f : 00000000`00000010 fffff880`0553bab0 00000000`00000010 00000000`00010286 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xa4c00
fffff880`0bc4f5e0 fffff880`04d640ac : fffff880`051ba300 fffff880`0bc4f6d9 fffffa80`0d2ff000 00000000`00000000 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]!nvDumpConfig+0x24b7cf
fffff880`0bc4f620 fffff880`05520945 : fffff880`0bc4f950 fffff880`0bc4f7a9 fffff880`0bc4f950 fffff880`0bc4f950 : [COLOR=#ff0000][I][B]nvlddmkm[/B][/I][/COLOR]+0xa40ac
fffff880`0bc4f740 fffff880`055b0899 : 00000000`00000000 00000000`00000000 00000000`4e562a2a 00000000`01000003 : [COLOR=#ff0000][I][B]nvlddmkm!nvDumpConfig[/B][/I][/COLOR]+0x230585
fffff880`0bc4f810 fffff880`05a4ef50 : 00000000`00000000 00000000`00000000 fffff880`0bc4f950 00000000`00000018 : [COLOR=#ff0000][I][B]nvlddmkm!nvDumpConfig[/B][/I][/COLOR]+0x2c04d9
fffff880`0bc4f840 fffff880`05a42093 : 00000000`00000000 00000000`00000000 fffff880`0bc4fca0 00000000`00000003 : [COLOR=#ff0000][B][I]dxgkrnl!DXGADAPTER[/I][/B][/COLOR]::[COLOR=#ff0000][I][B]DdiEscape[/B][/I][/COLOR]+0x50
fffff880`0bc4f870 fffff960`00271b32 : 00000000`6201123d fffffa80`0a5eb060 00000000`00388e30 00000000`00000020 : [COLOR=#ff0000][I][B]dxgkrnl!DxgkEscape[/B][/I][/COLOR]+0x7af
fffff880`0bc4fbf0 fffff800`0348ee53 : fffffa80`0a5eb060 fffff880`00000000 00000000`00000000 00000000`00000000 : win32k!NtGdiDdDDIEscape+0x12
fffff880`0bc4fc20 000007fe`fee913ea : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0bc4fc20)
00000000`0012d538 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x000007fe`fee913ea

Okay, so...

We start with a few DirectX Kernel Dxgk / Ddi calls. This is pretty advanced and I am not exactly sure what Escape implies, but the Ddi is the Device Driver Interface. Pair this along with the DirectX Kernel, and I can only imagine that the graphics driver is using it to control the output, as a graphics driver must ensure that its graphics device produces the required output.

We then see various nvlddmkm.sys (nVidia video driver) calls. Again, I am unsure as to what nvDumpConfig implies. After the nVidia video driver calls, we hit VfZwSetValueKey which creates or replaces a registry key's value entry. Two more calls up and we have NtSetValueKey which is the same call only the Nt indicates that it occurred in user-mode. We then see the VfCheckUserHandle call. If I am correct in my analysis, this indicates that a handle that was visible to user-mode was accessed in kernel-mode and does NOT have an OBJ_KERNEL_HANDLE attribute set. If a driver forgot to specify OBJ_KERNEL_HANDLE when creating a handle, it will end up creating a user-mode handle which in most cases is bad because user-mode code can now access the object than it may or may not have had access to otherwise.

If we take a look at our failure bucket ID - FAILURE_BUCKET_ID: X64_0xc4_f6_VRF_nvlddmkm+995d1

We can see that the nVidia video driver was blamed. Given all the DirectX Kernel calls leaves me curious about your RAM as well, although we'll worry about that if we have to. For now, 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.

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

E1G6032E.sys - Wed May 28 19:14:51 2008

^^ Intel Ethernet drivers, pretty old. I'd check for an update - http://downloadcenter.intel.com/Default.aspx

Regards,

Patrick
 
Patrick said:
The first bug check is of the IRQL_NOT_LESS_OR_EQUAL (a) bug check.

Check for any VMware updates - VMware Support & Downloads for Desktop, Application & Data Center Virtualization | United States

If there aren't any, I'd suggest removing the software entirely for temporary troubleshooting purposes.
Click to expand...

I'll do this tonight.

Patrick said:
Moving on, the next bug check is of the DRIVER_VERIFIER_DETECTED_VIOLATION (c4) bug check.

If we take a look at our failure bucket ID - FAILURE_BUCKET_ID: X64_0xc4_f6_VRF_nvlddmkm+995d1

We can see that the nVidia video driver was blamed. Given all the DirectX Kernel calls leaves me curious about your RAM as well, although we'll worry about that if we have to. For now, 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.
Click to expand...

I've run through four certified drivers (with clean installs). I am now on the latest 331.82, and it crashed again at 4am. Dump will be attached when it is finished uploading.

Is this possibly a HARDWARE issue? I ask because at one point I became convinced the card was faulty (and out of warranty). Win7 will occasionally drop to basic colour mode, saying it recovered from a graphics problem. Can't remember what else led me to believe the card is borked. It runs Furmark for 20 minutes just fine...

I pulled that card and put in a Quadro FX1800 after uninstalling the original drivers. Took much longer, but it still crashed so perhaps we have to chase down that RAM angle you were speaking of...

Patrick said:
E1G6032E.sys - Wed May 28 19:14:51 2008

^^ Intel Ethernet drivers, pretty old. I'd check for an update - http://downloadcenter.intel.com/Default.aspx

Regards,

Patrick
Click to expand...

Sadly for that card they suggest just running with the windows provided driver. Only older OSes have intel provided drivers.

https://downloadcenter.intel.com/Se...ntroller&ProdId=1938&LineId=976&FamilyId=2280
 
Is this possibly a HARDWARE issue?
Click to expand...

Yes, especially now since you mentioned you pulled the video card and you're still receiving crashes. We can run through some RAM diagnostics. Run a 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
 
Patrick said:
Is this possibly a HARDWARE issue?
Click to expand...

Yes, especially now since you mentioned you pulled the video card and you're still receiving crashes. We can run through some RAM diagnostics. Run a Memtest for NO LESS than ~8 passes (several hours):
Click to expand...

I have 6 x 2GB of RAM. Should I test each stick individually (I see this referenced elsewhere)? I have run memtest on all 12GB for at least 4 passes, no problems.

It seems there is a known, and now acknowledged problem with Nvidia drivers beyond 314.22 on 400/500 series cards. I will follow some of their troubleshooting suggestions and report back as well...
 
Go through no less than ~8 with all sticks installed, and if you'd like you can then test one at a time.

Keep me updated.

Regards,

Patrick
 
Patrick said:
Go through no less than ~8 with all sticks installed, and if you'd like you can then test one at a time.

Keep me updated.

Regards,

Patrick
Click to expand...

LOL--so this PC is also our home PVR and the wife's TV programs have been coming fast and furious. Haven't had the time to drop down to memtest for a proper go of it. However I did have time to do a manual purge of all things Nvidia, including all registry entries. The newest driver (331.82) is supposed to fix the issue with 400/500 series video cards. I had installed only the GFX driver, PhysX and the GeForce Experience. When I tried to run GeForce Experience I immediately blue-screened, and then I remembered that many times in the past I would try to launch it and it would simply do nothing.

Nuking everything manually again I installed ONLY the driver--no PhysX or Experience. I'm on day two of no lock-ups.

I made two other changes that were suggested in the Nvidia forums that I will leave here for others experiencing the same problem. I changed the "MANAGE 3D SETTINGS", "POWER MANAGEMENT MODE" to "Prefer Maximum Performance". There is suspicion that their code to dynamically adjust power draw is causing the problem.

Another bizarre occurance is that when I'd let GeForce Experience supply "optimal settings" for Battlefield 3 I got a very smooth frame rate. Without Experience installed, choosing the very same options manually resulted in choppy performance. I had to disable AA and Ambient Occlusion.

Not necessarily asking for comment on that--but leaving it for others.

Will report back when there are no TV programs to record (probably post weekend).

Oh, and Verifier has been running the last two days as well--no BSOD yet!

*edit: turns out that "crashing out" problem I referred to long ago has a name--TDR.
 
Yep, TDR is when the display driver cannot recover in time so you get a 0x116.

Keep me updated since the latest changes.

Regards,

Patrick
 

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

Back
Top