Solved Dell XPS M1530 Startup Repair Loop, Offline SFC does NOT function

[Z92435]

So to do it via the installation disc, what I did was started it like I was going to install. I immediately hit Shift+F10 once it loaded. Then I typed

regedit.exe /s "C:\users\mike\documents\test.reg"​

but there was no confirmation as to whether it did anything. I assumed it worked because there was also no error message. However, just to be sure, I then typed the command

regedit.exe "C:\users\mike\documents\test.reg"​

and it said running could possibly change the system setup (or something to that effect) and to only select yes to continue if I trusted the source. So I would say this was a successful test run for what you are trying to do.

As to how to replace the Windows file, I would do it via the installation disc as with the .reg file. Start the command prompt with Shift + F10 when the install disc loads. Then run the command

robocopy /s /r:5 /w:0 /xj C:\Windows D:\Windows​

I am assuming you are copying from the current system drive (assumed as C: ) to the secondary system drive (assumed as D: ). I do not know how familiar you are with the robocopy command, but I find it does the best job of replacing system files. As I said, if you do not install any programs and only install device drivers and possibly Windows Updates (though the more I think about it, the more I think this may be a bad idea unless you know the exact state of the updates when the machine went kaput), the Windows directory should be clean enough to do the above steps.

I am thinking the Windows updates may be an issue with the transplant scenario... If you know the exact state of the updates, that would go a long way to making this work.

Well, the chkdsk just concluded, so I'm going to start with the backing up of registry(s) and all that, followed up by finding and uploading the ntbtlog.txt and minidump. I was able to confirm that regedit.exe does work from the command prompt using either WindowsRE or an installation disk, which is nice.

Regarding the update status of the computer, as far as I know, I've managed to update it to as current as it can get, with SP1 and everything. But, if there's a way to check on how to keep a log of those updates, I can certainly attempt to keep a copy. As for robocopy, I'm sorry to say that I've never used it, so I'm totally mystified as to what those slash commands you issued in that line are. However, if that's what is needed, I can certainly do a good "monkey see, monkey do".

All right. First things first. Can we talk about how to get minidump enabled? Or, is it enabled by default?

 

[writhziden]

I edited my previous post again for enabling minidump (I had missed your second response).

For robocopy, I can explain what the flags do. /s is just to make sure all files are copied from all subdirectories that are not empty. /r is a retry flag, so 5 retries. /w tells how long to wait between retries, but it really doesn't matter since when you run robocopy in your case, Windows should not be running to need to wait for a file to stop being accessed. /xj excludes junctions (links to folders) and only copies actual folders.

Do your best to get the new Windows installation up to the same update status as the previous. If you are a little off, hopefully it will not cause issues. I imagine it will cause issues if you are off by 20+ updates, but I think if you can get to within 10, it should work. This is just somewhat speculation on my part, but I'm trusting my gut.

 

[Z92435]

I edited my previous post again for enabling minidump (I had missed your second response).

For robocopy, I can explain what the flags do. /s is just to make sure all files are copied from all subdirectories that are not empty. /r is a retry flag, so 5 retries. /w tells how long to wait between retries, but it really doesn't matter since when you run robocopy in your case, Windows should not be running to need to wait for a file to stop being accessed. /xj excludes junctions (links to folders) and only copies actual folders.

Do your best to get the new Windows installation up to the same update status as the previous. If you are a little off, hopefully it will not cause issues. I imagine it will cause issues if you are off by 20+ updates, but I think if you can get to within 10, it should work. This is just somewhat speculation on my part, but I'm trusting my gut.

Okay. That makes sense. I'll also reinstall Microsoft Office on the donor drive, since I think all of the updates that runs through Windows Update are Office, Silverlight, Status updates, SP1, and .Net Framework, all of which can and will be natively updated by the Windows Update application, except for the Office items, which I can solve simply by reinstalling it.

As for the progress of things, I'm currently backing up the "System" and "System32" folders from the C: drive, as well as the three copies of the registry, Spybot's backup, and an image to ensure that even if everything goes to hell, I'll hopefully have something to restore the drive from. I copy and pasted all of these files and folders using UBCD, as well as using UBCD to make the image, so hopefully it'll have copied everything and not ignored anything hidden.

I've attached the zipped minidump onto this message as an attachment, since I can't view it via a PC right now (I'm typing this on a Mac). And, you can find the ntbtlog.txt file here, since it was too big to upload.

 

[writhziden]

I do not think the log is too helpful. It just says what was and was not loaded. I do not see anything that indicates that it was unable to load a driver, only message that I would expect with Safe Mode regarding whether a driver was loaded or not per Safe Mode's settings to only load critical drivers...

[list=1]
[*]
Loading Dump File [D:\Kingston\BSODDmpFiles\Z92435\Minidump\021012-84022-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?ffffffff`82f2aad4?
Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16905.x86fre.win7_gdr.111025-1503
Machine Name:
Kernel base = 0x82e04000 PsLoadedModuleList = 0x82f4c810
Debug session time: Fri Feb 10 07:43:14.135 2012 (UTC - 7:00)
System Uptime: 0 days 0:52:16.961
Loading Kernel Symbols
...............................................................
................................................................
....................................
Loading User Symbols
Loading unloaded module list
.....
0: kd> !apnalyze -v
No export apnalyze found
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 84e2fb60, Physical Device Object of the stack
Arg3: 82f2aae0, Functional Device Object of the stack
Arg4: 8550d008, The blocked IRP

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


DRVPOWERSTATE_SUBCODE:  3

IMAGE_NAME:  pci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbf14

MODULE_NAME: pci

FAULTING_MODULE: 88c75000 pci

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x9F

CURRENT_IRQL:  0

STACK_TEXT:  
82f2aa94 82e40054 0000009f 00000003 84e2fb60 nt!KeBugCheckEx+0x1e
82f2ab00 82e3f8e8 82f2abac 00000000 82f37280 nt!PopCheckIrpWatchdog+0x1f5
82f2ab38 82e6e18d 82f45a20 00000000 5178e3b2 nt!PopCheckForIdleness+0x73
82f2ab7c 82e6e131 82f2dd20 82f2aca8 00000001 nt!KiProcessTimerDpcTable+0x50
82f2ac68 82e6dfee 82f2dd20 82f2aca8 00000000 nt!KiProcessExpiredTimerList+0x101
82f2acdc 82e6c34e 0003117e a5457d48 82f37280 nt!KiTimerExpiration+0x25c
82f2ad20 82e6c178 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb
82f2ad24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  0x9F_3_nvlddmkm_IMAGE_pci.sys

BUCKET_ID:  0x9F_3_nvlddmkm_IMAGE_pci.sys

Followup: MachineOwner
---------
[*]
Loading Dump File [D:\Kingston\BSODDmpFiles\Z92435\Minidump\021012-108264-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16905.x86fre.win7_gdr.111025-1503
Machine Name:
Kernel base = 0x82e3e000 PsLoadedModuleList = 0x82f86810
Debug session time: Fri Feb 10 06:49:40.536 2012 (UTC - 7:00)
System Uptime: 0 days 0:12:32.487
Loading Kernel Symbols
...............................................................
................................................................
..................................
Loading User Symbols
Loading unloaded module list
.......
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Unknown bugcheck code (8086)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

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


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x8086

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 88e2e451 to 82f1ae0b

STACK_TEXT:  
82f64b24 88e2e451 00008086 8663a524 8579e000 nt!KeBugCheck+0x14
WARNING: Stack unwind information not available. Following frames may be wrong.
82f64bd4 88e5f4db 00000001 82f69600 85802730 iaStor+0xa451
82f64c6c 88e298a3 8579e000 00000000 82ea64f5 iaStor+0x3b4db
82f64cd4 82ea6358 82f67d20 82f71280 00000000 iaStor+0x58a3
82f64d20 82ea6178 00000000 0000000e 00000000 nt!KiRetireDpcList+0xd5
82f64d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38


STACK_COMMAND:  kb

FOLLOWUP_IP: 
iaStor+a451
88e2e451 ??              ???

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  iaStor+a451

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: iaStor

IMAGE_NAME:  iaStor.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  462f9da3

FAILURE_BUCKET_ID:  0x8086_iaStor+a451

BUCKET_ID:  0x8086_iaStor+a451

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

[*]
Loading Dump File [D:\Kingston\BSODDmpFiles\Z92435\Minidump\021012-40201-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16905.x86fre.win7_gdr.111025-1503
Machine Name:
Kernel base = 0x82e4f000 PsLoadedModuleList = 0x82f97810
Debug session time: Fri Feb 10 04:31:05.742 2012 (UTC - 7:00)
System Uptime: 0 days 0:01:42.474
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
.....
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

VIDEO_TDR_FAILURE (116)
Attempt to reset the display driver and recover from timeout failed.
Arguments:
Arg1: 8ba52008, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: 92041800, The pointer into responsible device driver module (e.g. owner tag).
Arg3: 00000000, Optional error code (NTSTATUS) of the last failed operation.
Arg4: 00000002, Optional internal context dependent data.

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

Unable to load image \SystemRoot\system32\DRIVERS\nvlddmkm.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nvlddmkm.sys
*** ERROR: Module load completed but symbols could not be loaded for nvlddmkm.sys

FAULTING_IP: 
nvlddmkm+c800
92041800 55              push    ebp

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_TDR_FAULT

CUSTOMER_CRASH_COUNT:  1

BUGCHECK_STR:  0x116

CURRENT_IRQL:  0

STACK_TEXT:  
8ea7bb74 91576c26 00000116 8ba52008 92041800 nt!KeBugCheckEx+0x1e
8ea7bb98 91577a45 92041800 00000000 00000002 dxgkrnl!TdrBugcheckOnTimeout+0x8d
8ea7bbbc 9298e92c 00000000 00000102 891f6788 dxgkrnl!TdrIsRecoveryRequired+0xb8
8ea7bc34 929b8944 fffffcfb 000018d8 00000000 dxgmms1!VidSchiReportHwHang+0x3c0
8ea7bc5c 929b9065 00000000 00000000 00000000 dxgmms1!VidSchiCheckHwProgress+0x68
8ea7bc98 929958f0 8ea7bc90 88fec5a0 89350dd0 dxgmms1!VidSchiWaitForSchedulerEvents+0x1b1
8ea7bd28 929ba3c9 891f6788 82e8b3f1 891f6788 dxgmms1!VidSchiScheduleCommandToRun+0xaa
8ea7bd3c 929ba485 891f6788 00000000 89337510 dxgmms1!VidSchiRun_PriorityTable+0xf
8ea7bd50 8305da55 891f6788 a4c4cdd3 00000000 dxgmms1!VidSchiWorkerThread+0x7f
8ea7bd90 82f0f219 929ba406 891f6788 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


STACK_COMMAND:  .bugcheck ; kb

FOLLOWUP_IP: 
nvlddmkm+c800
92041800 55              push    ebp

SYMBOL_NAME:  nvlddmkm+c800

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nvlddmkm

IMAGE_NAME:  nvlddmkm.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a37c5a5

FAILURE_BUCKET_ID:  0x116_IMAGE_nvlddmkm.sys

BUCKET_ID:  0x116_IMAGE_nvlddmkm.sys

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


[/list]

1. This crash is due to the system sending a device driver the signal to turn itself off or turn itself on during a power cycle such as during sleep, hibernate, shut down, or startup. The device or device driver failed to respond to the signal and so the system crashed to force the power state. The most common components to cause this are network adapters or display card adapters. Could be caused by either the devices themselves or their drivers.
2. This may have been a Vista crash, which is why it may not be recognized. Points to Intel storage drivers.
3. Stop 0x116, see below

I am seeing what I would expect from a laptop that was upgraded to Windows 7 from Vista. There are a lot of out of date drivers. While this can cause conflicts, it does not always. I have a Toshiba laptop from 2007 that runs Windows 7 just fine with many of the same outdated drivers. The only concern I do have is the graphics card driver due to the Stop 0x116 error.

These are all stop 0x116 VIDEO_TDR_FAILURE conditions.

It's not a true crash, in the sense that the bluescreen was initiated only because the combination of video driver and video hardware was being unresponsive, and not because of any synchronous processing exception.

Since Vista, the "Timeout Detection and Recovery" (TDR) components of the OS video subsystem have been capable of doing some truly impressive things to try to recover from issues which would have caused earlier OSs like XP to crash. As a last resort, the TDR subsystem sends the video driver a "please restart yourself now!" command and waits a few seconds. If there's no response, the OS concludes that the video driver/hardware combo has truly collapsed in a heap, and it fires off that stop 0x116 BSOD.

If playing with video driver versions hasn't helped, make sure the box is not overheating. Try removing a side panel and aiming a big mains fan straight at the motherboard and GPU. Run it like that for a few hours or days - long enough to ascertain whether cooler temperatures make a difference. If so, it might be as simple as dust buildup and subsequently inadequate cooling.

The above quote was taken from http://www.sevenforums.com/crashes-debugging/25912-bsod.html#post280172, which is linked to in usasma's thread about this error. More information can be found in the first three posts of usasma's thread outlining http://www.sevenforums.com/crash-lo...op-0x116-video_tdr_error-troubleshooting.html.

 

[Z92435]

I do not think the log is too helpful. It just says what was and was not loaded. I do not see anything that indicates that it was unable to load a driver, only message that I would expect with Safe Mode regarding whether a driver was loaded or not per Safe Mode's settings to only load critical drivers...

[LIST=1]
[*]
Loading Dump File [D:\Kingston\BSODDmpFiles\Z92435\Minidump\021012-84022-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

DbsSplayTreeRangeMap::Add: ignoring zero-sized range at ?ffffffff`82f2aad4?
Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16905.x86fre.win7_gdr.111025-1503
Machine Name:
Kernel base = 0x82e04000 PsLoadedModuleList = 0x82f4c810
Debug session time: Fri Feb 10 07:43:14.135 2012 (UTC - 7:00)
System Uptime: 0 days 0:52:16.961
Loading Kernel Symbols
...............................................................
................................................................
....................................
Loading User Symbols
Loading unloaded module list
.....
0: kd> !apnalyze -v
No export apnalyze found
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 84e2fb60, Physical Device Object of the stack
Arg3: 82f2aae0, Functional Device Object of the stack
Arg4: 8550d008, The blocked IRP

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


DRVPOWERSTATE_SUBCODE:  3

IMAGE_NAME:  pci.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbf14

MODULE_NAME: pci

FAULTING_MODULE: 88c75000 pci

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x9F

CURRENT_IRQL:  0

STACK_TEXT:  
82f2aa94 82e40054 0000009f 00000003 84e2fb60 nt!KeBugCheckEx+0x1e
82f2ab00 82e3f8e8 82f2abac 00000000 82f37280 nt!PopCheckIrpWatchdog+0x1f5
82f2ab38 82e6e18d 82f45a20 00000000 5178e3b2 nt!PopCheckForIdleness+0x73
82f2ab7c 82e6e131 82f2dd20 82f2aca8 00000001 nt!KiProcessTimerDpcTable+0x50
82f2ac68 82e6dfee 82f2dd20 82f2aca8 00000000 nt!KiProcessExpiredTimerList+0x101
82f2acdc 82e6c34e 0003117e a5457d48 82f37280 nt!KiTimerExpiration+0x25c
82f2ad20 82e6c178 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb
82f2ad24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  0x9F_3_nvlddmkm_IMAGE_pci.sys

BUCKET_ID:  0x9F_3_nvlddmkm_IMAGE_pci.sys

Followup: MachineOwner
---------
[*]
Loading Dump File [D:\Kingston\BSODDmpFiles\Z92435\Minidump\021012-108264-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16905.x86fre.win7_gdr.111025-1503
Machine Name:
Kernel base = 0x82e3e000 PsLoadedModuleList = 0x82f86810
Debug session time: Fri Feb 10 06:49:40.536 2012 (UTC - 7:00)
System Uptime: 0 days 0:12:32.487
Loading Kernel Symbols
...............................................................
................................................................
..................................
Loading User Symbols
Loading unloaded module list
.......
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Unknown bugcheck code (8086)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

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


CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0x8086

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 88e2e451 to 82f1ae0b

STACK_TEXT:  
82f64b24 88e2e451 00008086 8663a524 8579e000 nt!KeBugCheck+0x14
WARNING: Stack unwind information not available. Following frames may be wrong.
82f64bd4 88e5f4db 00000001 82f69600 85802730 iaStor+0xa451
82f64c6c 88e298a3 8579e000 00000000 82ea64f5 iaStor+0x3b4db
82f64cd4 82ea6358 82f67d20 82f71280 00000000 iaStor+0x58a3
82f64d20 82ea6178 00000000 0000000e 00000000 nt!KiRetireDpcList+0xd5
82f64d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38


STACK_COMMAND:  kb

FOLLOWUP_IP: 
iaStor+a451
88e2e451 ??              ???

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  iaStor+a451

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: iaStor

IMAGE_NAME:  iaStor.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  462f9da3

FAILURE_BUCKET_ID:  0x8086_iaStor+a451

BUCKET_ID:  0x8086_iaStor+a451

Followup: MachineOwner
---------
[*]
Loading Dump File [D:\Kingston\BSODDmpFiles\Z92435\Minidump\021012-40201-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16905.x86fre.win7_gdr.111025-1503
Machine Name:
Kernel base = 0x82e4f000 PsLoadedModuleList = 0x82f97810
Debug session time: Fri Feb 10 04:31:05.742 2012 (UTC - 7:00)
System Uptime: 0 days 0:01:42.474
Loading Kernel Symbols
...............................................................
................................................................
...............................
Loading User Symbols
Loading unloaded module list
.....
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

VIDEO_TDR_FAILURE (116)
Attempt to reset the display driver and recover from timeout failed.
Arguments:
Arg1: 8ba52008, Optional pointer to internal TDR recovery context (TDR_RECOVERY_CONTEXT).
Arg2: 92041800, The pointer into responsible device driver module (e.g. owner tag).
Arg3: 00000000, Optional error code (NTSTATUS) of the last failed operation.
Arg4: 00000002, Optional internal context dependent data.

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

Unable to load image \SystemRoot\system32\DRIVERS\nvlddmkm.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nvlddmkm.sys
*** ERROR: Module load completed but symbols could not be loaded for nvlddmkm.sys

FAULTING_IP: 
nvlddmkm+c800
92041800 55              push    ebp

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_TDR_FAULT

CUSTOMER_CRASH_COUNT:  1

BUGCHECK_STR:  0x116

CURRENT_IRQL:  0

STACK_TEXT:  
8ea7bb74 91576c26 00000116 8ba52008 92041800 nt!KeBugCheckEx+0x1e
8ea7bb98 91577a45 92041800 00000000 00000002 dxgkrnl!TdrBugcheckOnTimeout+0x8d
8ea7bbbc 9298e92c 00000000 00000102 891f6788 dxgkrnl!TdrIsRecoveryRequired+0xb8
8ea7bc34 929b8944 fffffcfb 000018d8 00000000 dxgmms1!VidSchiReportHwHang+0x3c0
8ea7bc5c 929b9065 00000000 00000000 00000000 dxgmms1!VidSchiCheckHwProgress+0x68
8ea7bc98 929958f0 8ea7bc90 88fec5a0 89350dd0 dxgmms1!VidSchiWaitForSchedulerEvents+0x1b1
8ea7bd28 929ba3c9 891f6788 82e8b3f1 891f6788 dxgmms1!VidSchiScheduleCommandToRun+0xaa
8ea7bd3c 929ba485 891f6788 00000000 89337510 dxgmms1!VidSchiRun_PriorityTable+0xf
8ea7bd50 8305da55 891f6788 a4c4cdd3 00000000 dxgmms1!VidSchiWorkerThread+0x7f
8ea7bd90 82f0f219 929ba406 891f6788 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


STACK_COMMAND:  .bugcheck ; kb

FOLLOWUP_IP: 
nvlddmkm+c800
92041800 55              push    ebp

SYMBOL_NAME:  nvlddmkm+c800

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nvlddmkm

IMAGE_NAME:  nvlddmkm.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a37c5a5

FAILURE_BUCKET_ID:  0x116_IMAGE_nvlddmkm.sys

BUCKET_ID:  0x116_IMAGE_nvlddmkm.sys

Followup: MachineOwner
---------
[/LIST]

1. This crash is due to the system sending a device driver the signal to turn itself off or turn itself on during a power cycle such as during sleep, hibernate, shut down, or startup. The device or device driver failed to respond to the signal and so the system crashed to force the power state. The most common components to cause this are network adapters or display card adapters. Could be caused by either the devices themselves or their drivers.
2. This may have been a Vista crash, which is why it may not be recognized. Points to Intel storage drivers.
3. Stop 0x116, see below

I am seeing what I would expect from a laptop that was upgraded to Windows 7 from Vista. There are a lot of out of date drivers. While this can cause conflicts, it does not always. I have a Toshiba laptop from 2007 that runs Windows 7 just fine with many of the same outdated drivers. The only concern I do have is the graphics card driver due to the Stop 0x116 error.

These are all stop 0x116 VIDEO_TDR_FAILURE conditions.

It's not a true crash, in the sense that the bluescreen was initiated only because the combination of video driver and video hardware was being unresponsive, and not because of any synchronous processing exception.

Since Vista, the "Timeout Detection and Recovery" (TDR) components of the OS video subsystem have been capable of doing some truly impressive things to try to recover from issues which would have caused earlier OSs like XP to crash. As a last resort, the TDR subsystem sends the video driver a "please restart yourself now!" command and waits a few seconds. If there's no response, the OS concludes that the video driver/hardware combo has truly collapsed in a heap, and it fires off that stop 0x116 BSOD.

If playing with video driver versions hasn't helped, make sure the box is not overheating. Try removing a side panel and aiming a big mains fan straight at the motherboard and GPU. Run it like that for a few hours or days - long enough to ascertain whether cooler temperatures make a difference. If so, it might be as simple as dust buildup and subsequently inadequate cooling.

The above quote was taken from http://www.sevenforums.com/crashes-debugging/25912-bsod.html#post280172, which is linked to in usasma's thread about this error. More information can be found in the first three posts of usasma's thread outlining http://www.sevenforums.com/crash-lo...op-0x116-video_tdr_error-troubleshooting.html.

Well, I'll be honest that what concerns me when I fetched the minidump over to a windows machine and checked it out, was not the contents, but the fact that all of the logs were from much earlier than I had the machine in my possession, if I recall the timing correctly. Thus, this means that whatever this problem is, it's not even triggering much of a panic before things go to hell in a basket, which is a whole another level of bad, if one exists. I'm sorry to say that, since I was busy copying files and cloning the drive, I didn't have much time in browsing through the logs to see what went wrong. Nonetheless, I certainly can correct the outdated drivers once we get things to a spot where the installation processes can be access. Unless there's another way to do it that I'm not privy to?

Ugh. I'm not sure why, but nothing about this machine is ever easy. As soon as I'm sure that this thing has fully recovered, I'm shutting it down, putting it in my car and taking it back to my uncle. I actually had problems making the image of the drive before we do anything, since using UBCD apparently will take days to make it, and I simply don't have that kind of time frame. Similarly, both Windows and Macrium's Reflect Free apparently only works if it is already installed on a machine, which doesn't do me any good right now. Thus, without a real choice, I've now needed to turn to Acronis True Image Free/Trial again, since it can create an image back up using their rescue CD. Once that's finished, I'll put in the Windows 7 installation disk and reinstall over this drive.

Just to be absolutely certain, the general process is:

1. Reinstall the Windows 7 OS over the existing portion. I know I'll get the warning and consent to the creation of the "Various.Old" folders.
2. Once the OS installations are done, I immediately install Microsoft Office 2010, to make sure that their updates will come up also.
3. Using Windows Update, I update the crap out of this machine, including everything that I did to the other machine, until there is no updates left.
4. I boot using the installation disk again, log into WindowsRE, followed by Command Prompt.
5. Using the robocopy command you've so graciously given me, I set the copy target to be the entire "System" folder, from the tweaked drive to the original drive.
   • Do I do the "System32" and/or any other folders as well?
6. Try to reboot the original drive.
   • If it works, yipee!
   • If it doesn't work, go to step 7.
7. Put back the local machine and user registry backup from spybot into the original drive using regedit.exe from the command prompt. Then attempt step 6.
   • If it works, yipee!
   • If it doesn't work, go to step 8.
8. Tinker with Windows to see if it can repair it using SFC, Chkdsk, and others. If not, break down and cry. Then, once the tears stop, pop in Acronis True Image to restore both drives from the back up.

That about it?

 

[writhziden]

If you create a Macrium Windows based boot CD, you can backup the system image. I do it all the time that way.

Steps look good. Just make sure the system image works before proceeding through them so you know you have a valid state to return to.

 

[Z92435]

If you create a Macrium Windows based boot CD, you can backup the system image. I do it all the time that way.

Steps look good. Just make sure the system image works before proceeding through them so you know you have a valid state to return to.

Really? When I tried to create a Windows Boot CD, it told me that I had to upgrade to the full version for $XX. Thus, I just created the Linux CD. I will try again when I'm able to do so.

Also, Just wondering, how do I test the system image? It's currently a .tib that's sitting in a terabyte drive. Is there a program that can check its integrity against the original drive before I move the "System" folder over?

By the way, you never did answer if it was just "System" I'm moving or if there's anything else.

 

[writhziden]

I would move the whole Windows folder, myself. It won't overwrite anything that is already there if the old Windows installation had other files. It will only overwrite the files that exist on both installs.

To create the Windows CD, you do have to upgrade if you want to use their Windows CD. They also give an option to create your own for free using the Windows Automated Installation Kit. It requires a massive download, but it does work well and provide more device support.

Macrium has a system image tester. I imagine Acronis does, too. I personally won't touch Acronis software with all the reports that occur on here, but that is just my opinion and stance. Many others use it with no problems.

 

[Z92435]

I would move the whole Windows folder, myself. It won't overwrite anything that is already there if the old Windows installation had other files. It will only overwrite the files that exist on both installs.

To create the Windows CD, you do have to upgrade if you want to use their Windows CD. They also give an option to create your own for free using the Windows Automated Installation Kit. It requires a massive download, but it does work well and provide more device support.

Macrium has a system image tester. I imagine Acronis does, too. I personally won't touch Acronis software with all the reports that occur on here, but that is just my opinion and stance. Many others use it with no problems.

Meh. Just for safety's sake, I think I'll make the Macrium Windows Disk once the reinstall of Windows is done, burn the disk, then use it to clone the original disk once again before I move the Windows Folder over.

Speaking of the reinstall. Just how long is it supposed to take? It quickly zoomed through most of the steps along the list, but have been stuck at "completing Installation" for the longest time now. Is this a sign that even a reinstall won't save me? If so, I'm launching a formal complaint with whoever is running things in the cosmic sense.

 

[writhziden]

In my experience, the Windows install takes between 30 minutes to an hour. Anything beyond that is abnormal.

 

[Z92435]

In my experience, the Windows install takes between 30 minutes to an hour. Anything beyond that is abnormal.

Okay. Apparently, most of that hour or so will be spent stuck at the "Completing Installation" phase, making you think that it's not going to go through. So far, I've got the machine trying to download something like 149 updates so that it can get updated as much as possible. Just wondering, we know that a complete reinstall clears out all of the programs and such into "various.old" folders. Yet, a repair install solely acts on the System folder, is that correct?

The reason I'm asking is because while I know that you recommend I just do the whole of Windows, and that's what I'll do if I have to, but I'm wondering if any of the programs' settings or linkages will be destroyed by that replacement? I mean, I do have the original "System", "System32", "RegBack", and the Spybot Regs backed up, but the important thing here is to making sure that the programs' associations and such as maintained. But, I'm not well versed enough to know if any installations shove things into either the "System" or "System32" folders or not. Care to guess and enlighten me?

 

[writhziden]

The installations do put files into those folders. That is where program drivers go, registry entries, some .dll files, etc. But if the old installation still has all those things intact, then you shouldn't be overwriting too many things if any. The majority of software will not overwrite Windows files because it would change how Windows functions, but there are some exceptions. Without knowing what is installed on the computer, it is difficult to say whether copying files over will cause the system to stop working as it should and programs to stop working as they should.

Now, overwriting the registry is obviously going to have an adverse effect on how the programs function. How old are the .reg backups that you have? If they are fairly recent, as I assumed they were since you had just updated to 7, then those should sort out the software issues through the registry. I do not know how much overwriting the software might have done to Windows, but if you run the software, it should (hopefully) give complaints as to what files it is missing or are not as it expects, and you can go back to the old Windows folder and try to find those or find them from the system image you took.

 

[Z92435]

The installations do put files into those folders. That is where program drivers go, registry entries, some .dll files, etc. But if the old installation still has all those things intact, then you shouldn't be overwriting too many things if any. The majority of software will not overwrite Windows files because it would change how Windows functions, but there are some exceptions. Without knowing what is installed on the computer, it is difficult to say whether copying files over will cause the system to stop working as it should and programs to stop working as they should.

Now, overwriting the registry is obviously going to have an adverse effect on how the programs function. How old are the .reg backups that you have? If they are fairly recent, as I assumed they were since you had just updated to 7, then those should sort out the software issues through the registry. I do not know how much overwriting the software might have done to Windows, but if you run the software, it should (hopefully) give complaints as to what files it is missing or are not as it expects, and you can go back to the old Windows folder and try to find those or find them from the system image you took.

Writhziden,

Okay, so what you're saying is that while every program installation obviously does shove things into the "Windows" folder, when I do issue the replacement command, they most likely will NOT be wiped out, as long as they're individual files, rather than changes in an existing component of Windows itself. And, being that most third-party software are so against overwriting components of Windows itself, it's more likely to be adding another file or entry to the folder, rather than altering something existing. For example, much like how if I have {A,..., Z, 1, 2, 3} in the set, <X>, but just {A,..., Z} in the set, <Y>. When I use robocopy to move <Y> into <X>, while all entries between A to Z will be replaced, but {1, 2, 3} will not be changed at all. Is that right? If so, that makes total sense. If you wish, I can certainly provide you with a list of programs that was installed originally to see if anything could prove to be troublesome for the procedure.

Regarding the .reg backups that Spybot made, they were made maybe two or three days before the disaster happened, and I'd installed maybe two to three Windows update after they were made. Thus, I do not think that there's much discrepancy at all. Furthermore, all of the software that I did install or update between the time it was made and when it crashed are actually re-installable, so I'm not worried about that point at all. The point that I am slightly concerned about is that when I did carry out the reinstallation, it apparently nuked a whole truckload of drivers for the machine, which left quite a few things being labeled by that hateful little yellow question mark on device manager. I know what we talked about in the previous paragraph states that if those drivers existed in the originally installation, they shouldn't be touched. But, I still find myself wondering if I should just go ahead and re-install all of the drivers before I do the transplant. I would need to get the drivers from Dell, which would be for the Vista OS, and may be old, as you saw on the minidump logs. Is that better than just leaving it as it, or should I hunt down more recent drivers? If I should driver hunt, do you have any recommendations on where would be a good place?

Currently, I've got the donor all loaded up with all of the current updates via Windows Update, and I've got the Windows edition of Macrium Reflect Rescue Disk in the machine and am making yet another image to put on my TB drive, just in case something goes haywire. One can use the Macrium CD to selectively restore files or folders from the image, right? If so, being that I've got two of them and a buttload of back up files, I should be set for most of the issues.

 

[writhziden]

And yes, your variable set example is correct.

You will want to check the Hardware IDs for the devices missing drivers and use the Dell site to get those drivers. I think this is the best route. If you do a Google search for the Hardware IDs, you should be able to determine what hardware is missing drivers.

And, yes, you can mount the system image as a virtual hard drive through the Macrium CD, and you can pull files or folders off that virtual drive and put them on the actual hard drive.

 

[Z92435]

And yes, your variable set example is correct.

You will want to check the Hardware IDs for the devices missing drivers and use the Dell site to get those drivers. I think this is the best route. If you do a Google search for the Hardware IDs, you should be able to determine what hardware is missing drivers.

And, yes, you can mount the system image as a virtual hard drive through the Macrium CD, and you can pull files or folders off that virtual drive and put them on the actual hard drive.

All right. Now that the imaging is done, and I've installed all of the drivers I can find onto the donor drive, hopefully that will get it up to snuff so that a successful transplant can be done.

I just had a crazy thought: What if I robocopied everything from the "Windows" folder in the donor drive into the "Windows" folder in the donor drive's "Windows.old" folder, then moving it to the original drive? Maybe that'll get things closer to the original contents? Hmmm. Better try out the robocopy command once by making a copy of the "Windows" folder, so that I can do a easy recovery via rename if things do go bad.

Update: Lord. How long does a robocopy take? The screen never stops moving, but it's been like an hour already. Cloning and making an image neither took this long. Bah. Just saw something about multi thread that others are talking about using robocopy with. Should I try inputting that command when I do the formal brain transplant? Would that speed things up?

 

[writhziden]

I usually let robocopy run overnight, but that is due to copying 50-100 GB of items. I wouldn't think the Windows folder would take more than an hour or two... How long did it end up taking?

And the multithreaded option would be faster. I did not know about that feature, so thanks for that info.

 

[Z92435]

I usually let robocopy run overnight, but that is due to copying 50-100 GB of items. I wouldn't think the Windows folder would take more than an hour or two... How long did it end up taking?

And the multithreaded option would be faster. I did not know about that feature, so thanks for that info.

All right, Dr. Moreau-Frankenstein checking in here. As guano insane as this is, the first robocopy (i.e. Making a duplicate of the donor "Windows" folder") took seven (7!) hours. Being that cloning and imaging the entire disk, rather than just the Core OS files each took about an hour, I'm rather surprised that it took that long. Currently, the second transplant Robocopy is underway, with the donor "Window" folder being copied over to the original "Window" folder. Taking a tip from others online and your recommendation, I've enabled the MT option, setting it to 98 (/MT:98. Min or not specified is 1, and Max is 128). Here's hoping that it won't take seven hours for this transfer to complete.

Being that this transfer is from a filled folder to another filled folder, rather than an empty one, a lot of the log are labeled with "EXTRA file/folder", which means that those are folders which does not exist in the source folder, as far as I can tell via my google-fu. Now, I'm a bit afraid that it's not actually going to copy over much of anything, which would render the transplant procedure meaningless. Here's hoping that it'll start stating something other than the EXTRA files/folder soon.

I'll be in touch when there's more development. Wish me living monsters.

 

[writhziden]

You may need to add the /IS (include same) flag and /IT (include tweaked) flag. You can stop the current copy with CTRL + C if you'd like.

 

[Z92435]

You may need to add the /IS (include same) flag and /IT (include tweaked) flag. You can stop the current copy with CTRL + C if you'd like.

Wait, wait, wait. So, what's the command going to be like?

Robocopy /s /r:5 /w:0 /xj /MT:98 /IT /IS E:\Windows C:\Windows

I've got the Windows Installation CD in D:, the donor drive mounted via USB cradle as E:, and the original drive back in the machine as C:.

 

[writhziden]

Yes, that should work. Let us know if it spits out any errors with those flags setup.