Mr Snrub

So the system starts up okay in Safe Mode? I have seen this kind of behaviour on a client which had 2 AV products installed at the same time, and their services did not play well together, they deadlocked each other... did you change or install any security product just before the problem started?

Hmm, given what you have described and the explorer dump we have already seen, it sounds like a module that msgina.dll is supposed to call into has been unloaded "sometimes" when it comes to dim the screen when presenting the shutdown/restart/sleep options... Without resorting to time travel debugging, what we need are 3 dumps: - ADPlus hang mode dump of explorer before Start / Shut Down is clicked and the error does NOT occur - ADPlus hang mode dump of explorer before Start / Shut Down is clicked and the error DOES occur - ADPlus crash mode dump of explorer when it has the error 1. Make sure no applications or Explorer windows are running. 2. Open a command prompt and enter the commands: cd \progr* cd debug* (This should put you at the "C:\Program Files\Debugging Tools for Windows (x86)" prompt.) 3. Then enter this command: adplus -hang -ctcf -o c:\dumps -pn explorer.exe (This should produce a hang-mode dump of all explorer.exe processes and put them into a unique folder in c:\dumps, wait for the procedure to complete.) 4. Now enter the command: adplus -crash -ctcf -o c:\dumps -pn explorer.exe (Now there is a debugger attached to explorer.exe and it will generate a dump if the process raises an exception.) Following this command, click Start / Shut Down: - if the process does not crash, hit ESC on the dimmed window and rename the hang mode dump folder from step 3 to "Hang1NoCrash" - if the process does crash we should get a crash mode dump created and now there are 2 folders in c:\dumps - rename the first to "Hang1Crash" and "Crash" Repeat the procedure until you have hang mode dumps of the process when it did and did not crash, and the crash dump. By observing the difference in the 2 hang mode dumps, and the address of the exception in the crash dump, we may be able to figure out what is going on.

Good news is I didn't find anything suspicious in the kernel. Bad news is that means we are back to a user-mode dump of explorer.exe being the best way forward... What is the exact error message displayed, and when does it appear? (i.e. when you click on Shut Down and the list of shutdown options appears, or when you select one of the options) Does it stop waiting for you to click OK? If so, what happens when you do, and can you shut Windows down gracefully at all? When you have the explorer.exe has crashed error on screen and the disk activity has stopped, produce another complete memory dump at that point if you would.

WinSxs folder is the "side-by-side assemblies" store, owned by TrustedInstaller and you don't want to go deleting anything in there. The fact that TrustedInstaller owns it and even "Administrators" cannot write in there means that files you find in there shouldn't be suspect. There is a pretty good summary here: http://www.winvistaclub.com/f16.html As for the SoftwareDistribution folder, that's where the Windows Update client stores the files it downloads - I would only recommend clearing out this folder if you run into Windows Update problems.

The greying-out of an icon occurs when a Cut & Paste operation is half-way complete (i.e. you have marked a file and selected Cut, and now you need to specify where it should be pasted). If you press ESC does it restore all the icons? (This would be the equivalent of cancelling a Cut operation, so if this restores the icons then it looks like this is what is happening.) Is this just on your deskotp, or do you get the same effect in Explorer windows too? Do you have any Explorer extensions installed? Maybe something monitoring the clipboard, context menu extensions, etc...

Ahhhh, that explains it Complete dump is preferable for this issue, as we could do we seeing in kernel and user-mode space. Make a dump when the system is running normally, but with as few apps as possible running (including in the system tray) to keep the size and complexity down. (If we get a dump when explorer.exe has crashed during shutdown and presented a popup message then we might miss something that has already been unloaded - however we might need that next.)

The dump is corrupt :/ Kernel Complete Dump File: Full address space is available Missing image name, possible paged-out or corrupt data. *** WARNING: Unable to verify timestamp for Unknown_Module_01fe012d *** ERROR: Module load completed but symbols could not be loaded for Unknown_Module_01fe012d Debugger can not determine kernel base address Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible Product: WinNt, suite: TerminalServer SingleUserTS Built by: 2600.xpsp.080413-2111 Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720 Debug session time: Thu Jun 12 12:46:47.616 2008 (GMT+2) System Uptime: 0 days 14:33:48.212 Missing image name, possible paged-out or corrupt data. *** WARNING: Unable to verify timestamp for Unknown_Module_01fe012d *** ERROR: Module load completed but symbols could not be loaded for Unknown_Module_01fe012d Debugger can not determine kernel base address Loading Kernel Symbols Missing image name, possible paged-out or corrupt data. .Unable to read KLDR_DATA_TABLE_ENTRY at 01f0012d - NTSTATUS 0xC0000147 0: kd> lmft start end module name 01fe012d 0399025c Unknown_Module_01fe012d Unknown_Module_01fe012d unavailable (FFFFFFFE) Not much of the data is going to be reliable or usable... we don't even have the base address for the kernel, but we can try to hack it in... 0: kd> .reload nt=0x804d7000 0: kd> lmft start end module name 01fe012d 0399025c Unknown_Module_01fe012d Unknown_Module_01fe012d unavailable (FFFFFFFE) 804d7000 806e4000 nt ntkrpamp.exe Sun Apr 13 20:31:06 2008 (4802516A) 0: kd> lmvm nt start end module name 804d7000 806e4000 nt Loaded symbol image file: ntkrpamp.exe Image path: ntkrpamp.exe Image name: ntkrpamp.exe Timestamp: Sun Apr 13 20:31:06 2008 (4802516A) CheckSum: 001F442E ImageSize: 0020D000 File version: 5.1.2600.5512 Product version: 5.1.2600.5512 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 1.0 App File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: ntkrpamp.exe OriginalFilename: ntkrpamp.exe ProductVersion: 5.1.2600.5512 FileVersion: 5.1.2600.5512 (xpsp.080413-2111) FileDescription: NT Kernel & System LegalCopyright: © Microsoft Corporation. All rights reserved. 0: kd> !vm *** Virtual Memory Usage *** Physical Memory: 523883 ( 2095532 Kb) No Name for Paging File Current: 0 Kb Free Space: 0 Kb Minimum: 0 Kb Maximum: 0 Kb Available Pages: 359915 ( 1439660 Kb) ResAvail Pages: 431405 ( 1725620 Kb) Locked IO Pages: 397 ( 1588 Kb) Free System PTEs: 170367 ( 681468 Kb) Free NP PTEs: 32766 ( 131064 Kb) Free Special NP: 0 ( 0 Kb) Modified Pages: 172 ( 688 Kb) Modified PF Pages: 147 ( 588 Kb) NonPagedPool Usage: 9053 ( 36212 Kb) NonPagedPool Max: 65536 ( 262144 Kb) PagedPool 0 Usage: 1843320276 (7373281104 Kb) PagedPool 1 Usage: 68158125 ( 272632500 Kb) PagedPool 2 Usage: -740835438 (14216527432 Kb) PagedPool 3 Usage: 225447192 ( 901788768 Kb) PagedPool 4 Usage: 0 ( 0 Kb) PagedPool Usage: 1396090155 (5584360620 Kb) PagedPool Maximum: 92160 ( 368640 Kb) Shared Commit: 11105 ( 44420 Kb) Special Pool: 0 ( 0 Kb) Shared Process: 2891 ( 11564 Kb) PagedPool Commit: 33709 ( 134836 Kb) Driver Commit: 3669 ( 14676 Kb) Committed pages: 122721 ( 490884 Kb) Commit limit: 1021773 ( 4087092 Kb) Unable to read _EPROCESS at ffffff78 ProcessCommitUsage could not be calculated The paged pool stats are complete garbage, let's see if we can figure out the module list... 0: kd> dd nt!PsLoadedModuleList nt!PsLoadedModuleList 8055d720 89e81398 0: kd> dc 89e81398 89e81398 01f0012d 01f1012d 01f6012d 01f8012d -...-...-...-... 89e813a8 01fb012d 01fd012d 01fe012d 019b012e -...-...-....... 89e813b8 019b012f 01e10130 01ef0131 01e90132 /...0...1...2... 89e813c8 019b0133 01f70133 01fa0133 01fc0134 3...3...3...4... 89e813d8 01b90135 019f0136 01c90136 00000000 5...6...6....... 89e813e8 00000001 2b745058 00000292 66666600 ....XPt+.....fff 89e813f8 08666666 66086666 08666666 66086666 fff.ff.ffff.ff.f 89e81408 66666608 01016666 01010101 01010101 .fffff.......... 89e81418 01010101 01010101 01010101 01010101 ................ 89e81428 01010101 01010101 01010101 01010101 ................ The alleged location of the module list contains garbage - we can see where the debugger got the name "Unknown_Module_01fe012d", the garbage size and checkum from... Unfortunately none of the values around that address (89e81398) are even in the kernel address space, so I can't even begin to guess where the module list is/was Could you try setting the dump type to Kernel and produce another when you have the explorer.exe error message on the screen (without clicking OK)?

Looking at the 5 minidumps, it's not quite twice a day this occurs, the uptime varies from ~5 minutes to over 5 days. The bugchecks are consistent, and all point to the network card driver e1e5132.sys (Intel PRO/1000 LAN adapter). I'm guessing it is triggered by high network activity, or if the network cable is plugged in/out. No version information available in the minidump, but the date on the driver is 10/2007... http://www-307.ibm.com/pc/support/site.wss...ocid=MIGR-67829 "Intel PRO/1000 LAN adapter software for Windows 2000, XP - ThinkPad R61, R61i, T60, T60p, T61, T61p, X61, X61s, X61 Tablet, X300 ... Version: 9.7.251.0 (Build 152228) Release Date: 2007/12/18" If the driver update doesn't help, then I would recommend checking if it has an option for TCP checksum offloading, and disable it. (The option is located on the Advanced tab of the network card driver itself, different manufacturers refer to it as different things but it should have the word "offloading" in the property name.)

Well, you have the list of services that run in that process, and if the CPU usage is high for a few minutes then I would try the high-level approach of simply stopping services one at a time in that list and observing the CPU load. When it drops, you have identifed the service. Also, if it is not a worker thread (that is created, consumes CPU time and then dies), but is present all the time accumulating CPU time, then it should also vanish when the service involves is stopped, so you may not have to wait for the next occurrence.

Also, it might be useful to check which services you have running in that svchost.exe instance. From a command prompt, enter: tasklist /svc /FI "PID eq XXX"(Where XXX is the PID of the process.) It should give something like this as output (PID was 536 on my PC): C:\Windows\system32>tasklist /svc /FI "PID eq 536" Image Name PID Services ========================= ======== ============================================ svchost.exe 536 AudioEndpointBuilder, hidserv, Netman, PcaSvc, SysMain, TrkWks, UxSms, WdiSystemHost, WPDBusEnum, wudfsvc How frequently does that process consume CPU time, and for how long? Is it something like every N minutes, or at 18:00 every day, for example? If the total CPU usage is only 15% across your system, then it's not stealing time from other processes - is there a large amount of disk access at the same time?

One thing to be aware of is that you can't upgrade directly from 32-bit to 64-bit - it would require a clean install. Same if you wanted to downgrade from 64-bit to 32-bit - there are just too many differences for a setup process to automate.

Looks okay to me - first 2 are a couple of seed/secret related keys, last one is the log file used by Windows Update. Not sure why something in a Firefox profile would be hidden from the Windows API, but hopefully nothing executable cached in there anyway. Time to take a complete memory dump so we can take a look in the kernel: http://www.msfn.org/board/Creating-memory-dumps-t90244.html If you zip up the MEMORY.DMP file produced manually, plus your copies of KERNEL32.DLL and USER32.DLL we should be able to see if the binaries on disk have been modified or if something in memory is hooking them at load time.

All that information came from the second chance dump from explorer.exe. The location of the DLL doesn't give much away - anything could have installed it to system32 (I was interested to see if it happened to be under %ProgramFiles%). I was half expecting something like a no-cd stub exe for something, or emulation software like Daemon Tools which install kernel drivers which we wouldn't see a trace of in a user-mode dump... Let us know if Rootkit Revealer turns up anything - if it says everything looks clean then we may need a kernel dump to see if there are any hooks in there too.

Also, could you open a command prompt and enter the following commands, then copy the contents of t.txt and paste here: cd \ dir asfsipc.dll /s > t.txt (After pasting you can delete t.txt) This module is dated 1999, so pre-dates XP, I am interested to know where it is located in case it was installed by a 3rd party program.

You have a hooked "IsDebuggerPresent" function... Stack trace of crashing thread: 0:001> kv ChildEBP RetAddr Args to Child WARNING: Frame IP not in any known module. Following frames may be wrong. 0149fa74 7599840c 00000000 02e6acb0 0149fad0 0x3e6c530 0149fa90 75993a2f 00000002 010464f8 00000000 msgina!CDimmedWindow::Create+0x12 (FPO: [Non-Fpo]) 0149faa4 7ca78a05 0149fac0 0149fad0 010460f8 msgina!_ShellDimScreen+0x67 (FPO: [Non-Fpo]) 0149fcd8 7ca78cca 0001009c 00000002 0149fcfc shell32!CloseWindowsDialog+0x51 (FPO: [Non-Fpo]) 0149fce8 010341ff 0001009c 000001fa 010460f8 shell32!ExitWindowsDialog+0x2a (FPO: [Non-Fpo]) 0149fcfc 01026668 0001009c 00000000 00000111 explorer!CTray::_DoExitWindows+0x86 (FPO: [Non-Fpo]) 0149fd30 0101c43e 000001fa 00000111 010460f8 explorer!CTray::_Command+0x2da (FPO: [Non-Fpo]) 0149fde8 01001b5c 00040038 00000111 000001fa explorer!CTray::v_WndProc+0x981 (FPO: [Non-Fpo]) 0149fe0c 7e418734 00040038 00000111 000001fa explorer!CImpWndProc::s_WndProc+0x65 (FPO: [Non-Fpo]) 0149fe38 7e418816 01001b1d 00040038 00000111 user32!InternalCallWinProc+0x28 0149fea0 7e4189cd 000a04a0 01001b1d 00040038 user32!UserCallWinProcCheckWow+0x150 (FPO: [Non-Fpo]) 0149ff00 7e418a10 0149ff28 00000000 0149ff44 user32!DispatchMessageWorker+0x306 (FPO: [Non-Fpo]) 0149ff10 01001a35 0149ff28 00000000 010460f8 user32!DispatchMessageW+0xf (FPO: [Non-Fpo]) 0149ff44 0100ffd1 00000000 0149ffb4 77f76f42 explorer!CTray::_MessageLoop+0xd9 (FPO: [Non-Fpo]) 0149ff50 77f76f42 010460f8 0000005c 00000000 explorer!CTray::MainThreadProc+0x29 (FPO: [Non-Fpo]) 0149ffb4 7c80b713 00000000 0000005c 00000000 shlwapi!WrapperThreadProc+0x94 (FPO: [Non-Fpo]) 0149ffec 00000000 77f76ed3 0007fdbc 00000000 kernel32!BaseThreadStart+0x37 (FPO: [Non-Fpo]) Top address is bogus, does not exist (hence the crash): 0:001> dd 0x3e6c530 03e6c530 ???????? ???????? ???????? ???????? 03e6c540 ???????? ???????? ???????? ???????? 03e6c550 ???????? ???????? ???????? ???????? 03e6c560 ???????? ???????? ???????? ???????? 03e6c570 ???????? ???????? ???????? ???????? 03e6c580 ???????? ???????? ???????? ???????? 03e6c590 ???????? ???????? ???????? ???????? 03e6c5a0 ???????? ???????? ???????? ???????? Going back 1 frame in the stack, let's unassemble the caller: 0:001> u msgina!CDimmedWindow::Create msgina!CDimmedWindow::Create+0x12 msgina!CDimmedWindow::Create: 759983fa 8bff mov edi,edi 759983fc 55 push ebp 759983fd 8bec mov ebp,esp 759983ff 51 push ecx 75998400 51 push ecx 75998401 53 push ebx 75998402 56 push esi 75998403 57 push edi 75998404 8bf1 mov esi,ecx 75998406 ff1528139775 call dword ptr [msgina!_imp__IsDebuggerPresent (75971328)] IsDebuggerPresent is the function being called, and it is imported, so let's see where it goes: 0:001> dds msgina!_imp__IsDebuggerPresent 75971328 7c813123 kernel32!IsDebuggerPresent Now let's unassemble the function in kernel32... 0:001> u kernel32!IsDebuggerPresent kernel32!IsDebuggerPresent: 7c813123 e908946587 jmp 03e6c530 7c813128 cc int 3 7c813129 8b4030 mov eax,dword ptr [eax+30h] 7c81312c 0fb64002 movzx eax,byte ptr [eax+2] 7c813130 c3 ret 7c813131 90 nop 7c813132 90 nop 7c813133 90 nop The jmp instruction is the hook, and the address (0x03e6c530) is why we go boom. We can verify the memory-resident version of the kernel32.dll module with the copy on disk (provided courtesy of the symbols server): 0:001> !chkimg -d kernel32.dll 7c813123-7c813128 6 bytes - kernel32!IsDebuggerPresent [ 64 a1 18 00 00 00:e9 08 94 65 87 cc ] 6 errors : kernel32.dll (7c813123-7c813128) So 6 bytes in kernel32.dll have been modified by something, and there is the next question - what's hooking that OS function? Checked the other loaded modules (this only works for those we have symbols for, so genuine Microsoft Windows modules): 0:001> !for_each_module !chkimg @#ModuleName 8 errors : uxtheme (5ad8a69c-5ad8a6a3) 10 errors : user32 (7e42384e-7e4595c1) 6 errors : kernel32 (7c813123-7c813128) The uxtheme.dll hack I guess is the "allow use of unsigned themes" 3rd party crack: 0:001> !chkimg -d uxtheme.dll 5ad8a69c-5ad8a6a3 8 bytes - uxtheme!CThemeSignature::Verify+5 [ 81 ec 88 00 00 00 a1 18:33 f6 8b c6 c9 c2 08 00 ] 8 errors : uxtheme.dll (5ad8a69c-5ad8a6a3) 0:001> u 5ad8a69c 5ad8a6a3 uxtheme!CThemeSignature::Verify+0x5: 5ad8a69c 33f6 xor esi,esi 5ad8a69e 8bc6 mov eax,esi 5ad8a6a0 c9 leave 5ad8a6a1 c20800 ret 8 The user32.dll hack looks like more hooking, and possibly to the same not-present module as the IsDebuggerPresent hook: 0:001> !chkimg -d user32.dll 7e42384e-7e423852 5 bytes - user32!ChangeDisplaySettingsExA [ 8b ff 55 8b ec:e9 dd e6 a4 85 ] 7e4595bd-7e4595c1 5 bytes - user32!ChangeDisplaySettingsExW (+0x35d6f) [ 8b ff 55 8b ec:e9 9e 89 a1 85 ] 10 errors : user32.dll (7e42384e-7e4595c1) 0:001> u 7e42384e 7e423852 user32!ChangeDisplaySettingsExA: 7e42384e e9dde6a485 jmp 03e71f30 0:001> u 7e4595bd 7e4595c1 user32!ChangeDisplaySettingsExW: 7e4595bd e99e89a185 jmp 03e71f60 So 3 Microsoft modules are modified from their original content - are the binaries on disk hacked, or is there something memory resident which is hooking them at load time? Other than uxtheme.dll, have you replaced any DLLs manually? Does the crash occur in Safe Mode? I would recommend running RootkitRevealer and doing a full virus scan if you can't think of any software you have installed which might be hooking the functions for checking for an attached debugger (sometimes used by game cracks to prevent copy protection from detecting a debugger is attached when reverse-engineering, or by emulation software) and also the one for changing the display settings (which seems like a very odd function to hook). http://technet.microsoft.com/en-us/sysinte...s/bb897445.aspx

One at a time, or you won't know which solved the problem, if it goes away.

You're still looking at memory corruption I think. STOP 0x44 is typically caused by bad drivers. You still have VMWare installed. MULTIPLE_IRP_COMPLETE_REQUESTS (44) A driver has requested that an IRP be completed (IoCompleteRequest()), but the packet has already been completed. This is a tough bug to find because the easiest case, a driver actually attempted to complete its own packet twice, is generally not what happened. Rather, two separate drivers each believe that they own the packet, and each attempts to complete it. The first actually works, and the second fails. Tracking down which drivers in the system actually did this is difficult, generally because the trails of the first driver have been covered by the second. However, the driver stack for the current request can be found by examining the DeviceObject fields in each of the stack locations. Arguments: Arg1: fffffa800b9d2810, Address of the IRP Arg2: 0000000000001d00 Arg3: 0000000000000000 Arg4: 0000000000000000 1: kd> k 50 Child-SP RetAddr Call Site fffffa60`0cf99f38 fffff800`01e6193e nt!KeBugCheckEx fffffa60`0cf99f40 fffffa60`00b3f0c4 nt! ?? ::FNODOBFM::`string'+0x2185b fffffa60`0cf99f80 fffffa60`00b5a644 fltmgr!FltpFreeIrpCtrl+0x174 fffffa60`0cf99fb0 fffffa60`071e87af fltmgr!FltQueryDirectoryFile+0xb4 fffffa60`0cf99ff0 fffffa60`00b5bb92 luafv!LuafvNormalizeNameComponentEx+0x13f fffffa60`0cf9a0f0 fffffa60`00b5b711 fltmgr!FltpCallNormalizeNameComponentHandler+0x82 fffffa60`0cf9a150 fffffa60`00b5b587 fltmgr!FltpExpandShortNames+0x151 fffffa60`0cf9a1b0 fffffa60`00b5b3c9 fltmgr!FltpGetNormalizedFileNameWorker+0xb7 fffffa60`0cf9a1e0 fffffa60`00b5ba5f fltmgr!FltpGetNormalizedFileName+0x59 fffffa60`0cf9a220 fffffa60`00b4a0e9 fltmgr!FltpCreateFileNameInformation+0xaf fffffa60`0cf9a250 fffffa60`00b432fb fltmgr!HandleStreamListNotSupported+0x159 fffffa60`0cf9a290 fffffa60`00b4b094 fltmgr! ?? ::FNODOBFM::`string'+0x2a87 fffffa60`0cf9a330 fffffa60`0452ee1f fltmgr!FltGetFileNameInformation+0x174 fffffa60`0cf9a3c0 fffffa60`0452ef00 klif+0x17e1f fffffa60`0cf9a420 fffffa60`045460d6 klif+0x17f00 fffffa60`0cf9a4b0 fffffa60`00b3e05a klif+0x2f0d6 fffffa60`0cf9a540 fffffa60`00b3d32c fltmgr!FltpPerformPreCallbacks+0x28a fffffa60`0cf9a620 fffffa60`00b59256 fltmgr!FltpPassThroughInternal+0x3c fffffa60`0cf9a650 fffff800`02138cc3 fltmgr!FltpCreate+0x247 fffffa60`0cf9a700 fffff800`02132999 nt!IopParseDevice+0x5e3 fffffa60`0cf9a8a0 fffff800`02136884 nt!ObpLookupObjectName+0x5eb fffffa60`0cf9a9b0 fffff800`02142e30 nt!ObOpenObjectByName+0x2f4 fffffa60`0cf9aa80 fffff800`02143968 nt!IopCreateFile+0x290 fffffa60`0cf9ab20 fffff800`01eb0e33 nt!NtCreateFile+0x78 fffffa60`0cf9abb0 00000000`779b5fca nt!KiSystemServiceCopyEnd+0x13 00000000`04c5e778 00000000`00000000 0x779b5fca IRP = I/O Request Packet. First hint of memory corruption - we were handling an IRP, but the debugger doesn't believe that looks like one: 1: kd> !irp fffffa80`0b9d2810 IRP signature does not match, probably not an IRP What about the pool description of that "IRP"... 1: kd> !pool fffffa80`0b9d2810 Pool page fffffa800b9d2810 region is Unknown fffffa800b9d2000 size: 4b0 previous size: 0 (Allocated) Thre (Protected) fffffa800b9d24b0 size: 20 previous size: 4b0 (Free) .... fffffa800b9d24d0 size: 80 previous size: 20 (Allocated) Ntfr fffffa800b9d2550 size: 80 previous size: 80 (Allocated) Ntfr fffffa800b9d25d0 size: 130 previous size: 80 (Allocated) File (Protected) fffffa800b9d2700 size: 10 previous size: 130 (Free) FMng fffffa800b9d2710 size: f0 previous size: 10 (Allocated) MmCa *fffffa800b9d2800 size: 400 previous size: f0 (Free ) *Irp Pooltag Irp : Io, IRP packets fffffa800b9d2c00 size: 70 previous size: 400 (Allocated) Vad fffffa800b9d2c70 size: 10 previous size: 70 (Free) SeTd fffffa800b9d2c80 size: 70 previous size: 10 (Allocated) Vad fffffa800b9d2cf0 size: 1e0 previous size: 70 (Allocated) ALPC (Protected) fffffa800b9d2ed0 size: 130 previous size: 1e0 (Allocated) Irp Process: fffffa8006b98040 So it was tagged as an IRP, is now marked as free, but the pool allocation does not make the debugger believe it has the structure of an IRP... There is another IRP in the pool which hasn't completed yet, and the debugger says belongs to process fffffa8006b98040 so let's have a look at the memory contents of the good one... 1: kd> dq fffffa800b9d2ed0 fffffa800b9d2ed0+130-1 fffffa80`0b9d2ed0 20707249`0a13001e fffffa80`06b98040 fffffa80`0b9d2ee0 00000000`01180006 00000000`00000000 fffffa80`0b9d2ef0 00000000`00062900 00000000`00000000 fffffa80`0b9d2f00 fffffa80`06beca40 fffffa80`06beca40 fffffa80`0b9d2f10 00000000`00000000 00000000`00000000 fffffa80`0b9d2f20 01000000`01010001 00000000`02f03db0 fffffa80`0b9d2f30 00000000`00000000 fffffa80`06b98042 fffffa80`0b9d2f40 00000000`02f03db0 fffffa60`0457e008 fffffa80`0b9d2f50 00000000`003ad370 00000000`00000000 fffffa80`0b9d2f60 00000000`00000000 fffff880`07643e60 fffffa80`0b9d2f70 fffffa80`0b3896b0 fffffa80`0b9c4060 fffffa80`0b9d2f80 00000000`00000000 00000000`00000000 fffffa80`0b9d2f90 00000000`00000000 fffffa80`0b9d2fb0 fffffa80`0b9d2fa0 fffffa80`06bec980 00000000`00000000 fffffa80`0b9d2fb0 00000000`01000003 00000000`00000400 fffffa80`0b9d2fc0 00000000`00000000 00000000`00000000 fffffa80`0b9d2fd0 00000000`00000000 fffffa80`081bddf0 fffffa80`0b9d2fe0 fffffa80`06bec980 00000000`00000000 fffffa80`0b9d2ff0 00000000`00000000 00000000`00000000 We can see that the !irp command should work for an IRP object: 1: kd> !irp fffffa800b9d2ed0+10 Irp is active with 1 stacks 1 is current (= 0xfffffa800b9d2fb0) No Mdl: No System Buffer: Thread fffffa800b9c4060: Irp stack trace. cmd flg cl Device File Completion-Context >[ 3, 0] 0 1 fffffa80081bddf0 fffffa8006bec980 00000000-00000000 pending \FileSystem\Npfs Args: 00000400 00000000 00000000 00000000 (We add +10 because the header of the pool allocation is 16 (0x10) bytes - previous allocation size, current allocation size and owning PID - the real IRP data structure starts immediately after the header.) The owning process ID is the second quadword in the pool structure, which we can verify by checking the pool allocation: 1: kd> !pool fffffa80`06b98040 Pool page fffffa8006b98040 region is Nonpaged pool *fffffa8006b98000 size: 430 previous size: 0 (Allocated) *Proc (Protected) Pooltag Proc : Process objects, Binary : nt!ps So to check what process does our bad IRP belong to, we need to look at the second quadword from address fffffa800b9d2800: 1: kd> dq fffffa800b9d2800+8 fffffa800b9d2800+f fffffa80`0b9d2808 fffffa80`06bea600 Checking the pool allocation of this alleged process to ensure it is what we think: 1: kd> !pool fffffa80`06bea600 Pool page fffffa8006bea600 region is Nonpaged pool ... *fffffa8006bea5c0 size: 430 previous size: 40 (Allocated) *Proc (Protected) Pooltag Proc : Process objects, Binary : nt!ps Looks good so far - so what process is this? 1: kd> !process fffffa80`06bea600 1 PROCESS fffffa8006bea600 SessionId: 0 Cid: 04fc Peb: 7efdf000 ParentCid: 0290 DirBase: 1284f4000 ObjectTable: fffff88007825170 HandleCount: 588. Image: avp.exe VadRoot fffffa8006bfa560 Vads 554 Clone 0 Private 12762. Modified 1092. Locked 0. DeviceMap fffff88000007310 Token fffff88007965520 ElapsedTime 00:01:03.553 UserTime 00:00:00.764 KernelTime 00:00:00.655 QuotaPoolUsage[PagedPool] 145776 QuotaPoolUsage[NonPagedPool] 438928 Working Set Sizes (now,min,max) (16420, 50, 345) (65680KB, 200KB, 1380KB) PeakWorkingSetSize 16516 VirtualSize 191 Mb PeakVirtualSize 194 Mb PageFaultCount 22900 MemoryPriority BACKGROUND BasePriority 8 CommitCharge 13216 So, avp.exe owns an IRP which it wants to complete, but upon checking the packet the system believes it has already been completed and BOOM - bugcheck (by design). The IRP structure is in pool memory, starting at fffffa800b9d2800 for 0x400 bytes, unfortunately we can't get any clues as to what specific area of the allocation is corrupted like before, just 'something' in this range has been blitzed by 'something': 1: kd> dq /c4 fffffa800b9d2800 fffffa800b9d2c00-1 fffffa80`0b9d2800 20707249`0440000f fffffa80`06bea600 fffffa80`04286c10 00000000`00000000 fffffa80`0b9d2820 00000000`00060000 00000000`00000000 fffffa80`0b9d2830 fffffa80`0b9d2830 fffffa80`0b9d2840 00000000`00000000 00000000`0000001c 00000000`0d0b0000 00000000`00000000 fffffa80`0b9d2860 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2880 fffff880`08f01a10 00000000`00580012 fffffa80`04289060 fffffa80`042890a8 fffffa80`0b9d28a0 fffffa80`042890a8 fffff800`01ed94f0 fffff800`021fd700 00000000`00000000 fffffa80`0b9d28c0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d28e0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2900 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2920 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2940 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2960 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2980 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d29a0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d29c0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d29e0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2a00 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2a20 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2a40 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2a60 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2a80 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2aa0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2ac0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2ae0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2b00 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2b20 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2b40 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2b60 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0b9d2b80 00000000`00000000 00000000`00000000 fffffa80`04d5c030 00000000`00000000 fffffa80`0b9d2ba0 fffffa60`00b3f0f0 fffffa80`04d3f010 00000000`0000000c 00000000`00000000 fffffa80`0b9d2bc0 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`0688d900 fffffa80`0b9d2be0 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 Another apparent case of random memory locations being zeroed? I think avp.exe is Kaspersky AV, which has yet more kernel filter drivers that could be the root, or may be having a conflict with something like VMWare's filter driver. If it was dodgy RAM, I would expect very random memory corruption, leading to application crashes as much as bugchecks, all random. I would still say test uninstalling VMWare and run for a period of time to observe stability. "Not using VMWare" is not enough btw - the kernel filter drivers are still loaded and will be involved in I/O.

svchost.exe is a host service inside which many services can share a virtual address space - if any one of these services has a memory leak, bug or performance problem then the entire process will be affected, making it tricky at first glance to see which service is the problematic one. Read the following for a full, detailed breakdown of how to troubleshoot your issue: http://blogs.technet.com/askperf/archive/2...leshooting.aspx Once you identify the service consuming the CPU by isolating it into its own process, you can use the Services control panel applet to gracefully stop (and restart) the service instead of killing the hosting process, pulling the rug out from under all other hosted services in the same process who are simply victims.

Based on the first screenshot, the destination IP address was 82.98.235.216... DNS info on the IP address: http://private.dnsstuff.com/tools/ipall.ch...n=82.98.235.216 A quick search on that IP address brought up this: http://www.ca.com/securityadvisor/virusinf...s.aspx?id=69931 Other references to Vundo/Virtumonde: http://vil.nai.com/vil/Content/v_127690.htm http://www.virtumonde.net/ Given the referrer in the first image, and IE title bar in the second image implicate inetseeker.com, a search on "inetseeker vundo" brings up: http://www.spywareinfoforum.com/index.php?showtopic=99091 The above references have detailed guides on how to go about removing the adware, if that's what you have.

Unfortunately this leads to a bit of a dead-end, for me at least, as it is a corruption in nonpaged pool, and there's no clear way to see what did the corruption. For those interested, here is my working... IRQL_NOT_LESS_OR_EQUAL (a) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If a kernel debugger is available get the stack backtrace. Arguments: Arg1: 0000000000000008, memory referenced Arg2: 000000000000000c, IRQL Arg3: 0000000000000001, bitfield : bit 0 : value 0 = read operation, 1 = write operation bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status) Arg4: fffff80001e6e509, address which referenced memory TRAP_FRAME: fffffa600c844940 -- (.trap 0xfffffa600c844940) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=fffffa80043851a8 rbx=fffffa600c844a98 rcx=0000000000000000 rdx=fffffa80044e7880 rsi=fffffa8000000000 rdi=2000000070000000 rip=fffff80001e6e509 rsp=fffffa600c844ad0 rbp=fffffa8004389608 r8=0000000000000000 r9=0000000000000000 r10=fffff960000fd364 r11=fffff900c0811d10 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl nz na pe nc nt!KeSetEvent+0x289: fffff800`01e6e509 48894108 mov qword ptr [rcx+8],rax ds:00000000`00000008=???????????????? 0: kd> .trap 0xfffffa600c844940 0: kd> k *** Stack trace for last set context - .thread/.cxr resets it Child-SP RetAddr Call Site fffffa60`0c844ad0 fffff960`000fb7c6 nt!KeSetEvent+0x289 fffffa60`0c844b40 fffff960`000fd7d9 win32k!SetWakeBit+0xe6 fffffa60`0c844b70 fffff960`000fd5c0 win32k!PostThreadMessage+0x151 fffffa60`0c844bd0 fffff800`01e67e33 win32k!NtUserPostThreadMessage+0x25c fffffa60`0c844c20 00000000`775f34ba nt!KiSystemServiceCopyEnd+0x13 00000000`0253e828 00000000`00000000 0x775f34ba 0: kd> u nt!KeSetEvent+0x289-20 nt!KeSetEvent+0x269: fffff800`01e6e4e9 44894304 mov dword ptr [rbx+4],r8d fffff800`01e6e4ed 0fb74028 movzx eax,word ptr [rax+28h] fffff800`01e6e4f1 498b9788000000 mov rdx,qword ptr [r15+88h] fffff800`01e6e4f8 49098780000000 or qword ptr [r15+80h],rax fffff800`01e6e4ff 488b4208 mov rax,qword ptr [rdx+8] fffff800`01e6e503 488b0a mov rcx,qword ptr [rdx] fffff800`01e6e506 488908 mov qword ptr [rax],rcx fffff800`01e6e509 48894108 mov qword ptr [rcx+8],rax The unassembly at the end is the set of instructions leading up to the bugcheck, which occurs because RCX contains 0, and should be a memory address. Moving back to the previous instruction, the value in regsiter RCX (0) was placed into the memory address pointed to by RAX (fffffa80043851a8)... 0: kd> dq rax rax+1 fffffa80`043851a8 00000000`00000000 Moving back again, RCX was populated by the memory contents pointed to by RDX (fffffa80044e7880)... 0: kd> dq rdx rdx fffffa80`044e7880 00000000`00000000 Before that, RAX was populated by the memory contents pointed to by RDX+8... 0: kd> dq rdx+8 rdx+8 fffffa80`044e7888 fffffa80`043851a8 As we are using RDX as a memory pointer and using an offset in another instruction, it seems RDX is pointing to a data structure of some kind, we can check if it was a pool allocation: 0: kd> !pool rdx Pool page fffffa80044e7880 region is Nonpaged pool fffffa80044e7000 size: 130 previous size: 0 (Allocated) File (Protected) fffffa80044e7130 size: 80 previous size: 130 (Allocated) Muta (Protected) fffffa80044e71b0 size: 80 previous size: 80 (Allocated) MmSd fffffa80044e7230 size: 1e0 previous size: 80 (Allocated) CcSc fffffa80044e7410 size: 150 previous size: 1e0 (Allocated) Mdl fffffa80044e7560 size: 150 previous size: 150 (Allocated) File (Protected) fffffa80044e76b0 size: 10 previous size: 150 (Free) Irp *fffffa80044e76c0 size: 3a0 previous size: 10 (Allocated) *Wait Pooltag Wait : NtWaitForMultipleObjects fffffa80044e7a60 size: 1a0 previous size: 3a0 (Allocated) MmCi fffffa80044e7c00 size: 30 previous size: 1a0 (Allocated) MmSi ... The pool allocation starts at fffffa80044e76c0 and the next one starts at fffffa80044e7a60, so let's take a look at the data in between: 0: kd> dq fffffa80044e76c0 fffffa80044e7a60-1 fffffa80`044e76c0 74696157`023a0001 fffff800`01fa6548 fffffa80`044e76d0 fffffa80`0438e048 fffffa80`0438e048 fffffa80`044e76e0 fffffa80`0438fbb0 fffffa80`0438e040 fffffa80`044e76f0 fffffa80`044e7700 00000000`00010000 fffffa80`044e7700 fffffa80`04366738 fffffa80`04366738 fffffa80`044e7710 fffffa80`0438fbb0 fffffa80`04366730 fffffa80`044e7720 fffffa80`044e7730 00000000`00010001 fffffa80`044e7730 fffffa80`04385b58 fffffa80`04385b58 fffffa80`044e7740 fffffa80`0438fbb0 fffffa80`04385b50 fffffa80`044e7750 fffffa80`044e7760 fffff800`02010002 fffffa80`044e7760 fffffa80`043932b8 fffffa80`043932b8 fffffa80`044e7770 fffffa80`0438fbb0 fffffa80`043932b0 fffffa80`044e7780 fffffa80`044e7790 00000000`00010003 fffffa80`044e7790 fffffa80`0ad4deb8 fffffa80`0ad4deb8 fffffa80`044e77a0 fffffa80`0438fbb0 fffffa80`0ad4deb0 fffffa80`044e77b0 fffffa80`044e77c0 00000000`00010004 fffffa80`044e77c0 fffffa80`0ad4ddd8 fffffa80`0ad4ddd8 fffffa80`044e77d0 fffffa80`0438fbb0 fffffa80`0ad4ddd0 fffffa80`044e77e0 fffffa80`044e77f0 00000000`00010005 fffffa80`044e77f0 fffffa80`0ad4dcf8 fffffa80`0ad4dcf8 fffffa80`044e7800 fffffa80`0438fbb0 fffffa80`0ad4dcf0 fffffa80`044e7810 fffffa80`044e7820 00000000`00010006 fffffa80`044e7820 fffffa80`04385368 fffffa80`04385368 fffffa80`044e7830 fffffa80`0438fbb0 fffffa80`04385360 fffffa80`044e7840 fffffa80`044e7850 00000000`00010007 fffffa80`044e7850 fffffa80`04385288 fffffa80`04385288 fffffa80`044e7860 fffffa80`0438fbb0 fffffa80`04385280 fffffa80`044e7870 fffffa80`044e7880 00000000`00000000 fffffa80`044e7880 00000000`00000000 fffffa80`043851a8 fffffa80`044e7890 fffffa80`0438fbb0 fffffa80`043851a0 fffffa80`044e78a0 fffffa80`044e78b0 fffffa60`04010009 fffffa80`044e78b0 fffffa80`04375368 fffffa80`04375368 fffffa80`044e78c0 fffffa80`0438fbb0 fffffa80`04375360 fffffa80`044e78d0 fffffa80`044e78e0 00000000`0001000a fffffa80`044e78e0 fffffa80`04375288 fffffa80`04375288 fffffa80`044e78f0 fffffa80`0438fbb0 fffffa80`04375280 fffffa80`044e7900 fffffa80`044e7910 00000000`0001000b fffffa80`044e7910 fffffa80`043751a8 fffffa80`043751a8 fffffa80`044e7920 fffffa80`0438fbb0 fffffa80`043751a0 fffffa80`044e7930 fffffa80`044e7940 00000000`0001000c fffffa80`044e7940 fffffa80`0ad4eab8 fffffa80`0ad4eab8 fffffa80`044e7950 fffffa80`0438fbb0 fffffa80`0ad4eab0 fffffa80`044e7960 fffffa80`044e7970 00000000`0001000d fffffa80`044e7970 fffffa80`0ad4e9d8 fffffa80`0ad4e9d8 fffffa80`044e7980 fffffa80`0438fbb0 fffffa80`0ad4e9d0 fffffa80`044e7990 fffffa80`044e79a0 00000000`0001000e fffffa80`044e79a0 fffffa80`0ad4e8f8 fffffa80`0ad4e8f8 fffffa80`044e79b0 fffffa80`0438fbb0 fffffa80`0ad4e8f0 fffffa80`044e79c0 fffffa80`044e79d0 00000000`0001000f fffffa80`044e79d0 fffffa80`0a521e18 fffffa80`0a521e18 fffffa80`044e79e0 fffffa80`0438fbb0 fffffa80`0a521e10 fffffa80`044e79f0 fffffa80`044e7a00 00000000`00010010 fffffa80`044e7a00 fffffa80`0438ccd8 fffffa80`0438ccd8 fffffa80`044e7a10 fffffa80`0438fbb0 fffffa80`0438ccd0 fffffa80`044e7a20 fffffa80`044e7a30 00000000`00010011 fffffa80`044e7a30 fffffa80`04389608 fffffa80`04389608 fffffa80`044e7a40 fffffa80`0438fbb0 fffffa80`04389600 fffffa80`044e7a50 fffffa80`044e76d0 fffffa60`04010012 I reformatted the output for readability - it may not appear so, but there is a nice clear pattern here... it looks like a header of 16 bytes... 0: kd> db fffffa80044e76c0 fffffa80044e76c0+f fffffa80`044e76c0 01 00 3a 02 57 61 69 74-48 65 fa 01 00 f8 ff ff ..:.WaitHe...... ...followed by 13 blocks of 48 bytes, forming a list - the last item pointing back to the first: 0: kd> dq /c6 fffffa80044e76c0+10 fffffa80044e7a60-1 fffffa80`044e76d0 fffffa80`0438e048 fffffa80`0438e048 fffffa80`0438fbb0 fffffa80`0438e040 fffffa80`044e7700 00000000`00010000 fffffa80`044e7700 fffffa80`04366738 fffffa80`04366738 fffffa80`0438fbb0 fffffa80`04366730 fffffa80`044e7730 00000000`00010001 fffffa80`044e7730 fffffa80`04385b58 fffffa80`04385b58 fffffa80`0438fbb0 fffffa80`04385b50 fffffa80`044e7760 fffff800`02010002 fffffa80`044e7760 fffffa80`043932b8 fffffa80`043932b8 fffffa80`0438fbb0 fffffa80`043932b0 fffffa80`044e7790 00000000`00010003 fffffa80`044e7790 fffffa80`0ad4deb8 fffffa80`0ad4deb8 fffffa80`0438fbb0 fffffa80`0ad4deb0 fffffa80`044e77c0 00000000`00010004 fffffa80`044e77c0 fffffa80`0ad4ddd8 fffffa80`0ad4ddd8 fffffa80`0438fbb0 fffffa80`0ad4ddd0 fffffa80`044e77f0 00000000`00010005 fffffa80`044e77f0 fffffa80`0ad4dcf8 fffffa80`0ad4dcf8 fffffa80`0438fbb0 fffffa80`0ad4dcf0 fffffa80`044e7820 00000000`00010006 fffffa80`044e7820 fffffa80`04385368 fffffa80`04385368 fffffa80`0438fbb0 fffffa80`04385360 fffffa80`044e7850 00000000`00010007 fffffa80`044e7850 fffffa80`04385288 fffffa80`04385288 fffffa80`0438fbb0 fffffa80`04385280 fffffa80`044e7880 00000000`00000000 fffffa80`044e7880 00000000`00000000 fffffa80`043851a8 fffffa80`0438fbb0 fffffa80`043851a0 fffffa80`044e78b0 fffffa60`04010009 fffffa80`044e78b0 fffffa80`04375368 fffffa80`04375368 fffffa80`0438fbb0 fffffa80`04375360 fffffa80`044e78e0 00000000`0001000a fffffa80`044e78e0 fffffa80`04375288 fffffa80`04375288 fffffa80`0438fbb0 fffffa80`04375280 fffffa80`044e7910 00000000`0001000b fffffa80`044e7910 fffffa80`043751a8 fffffa80`043751a8 fffffa80`0438fbb0 fffffa80`043751a0 fffffa80`044e7940 00000000`0001000c fffffa80`044e7940 fffffa80`0ad4eab8 fffffa80`0ad4eab8 fffffa80`0438fbb0 fffffa80`0ad4eab0 fffffa80`044e7970 00000000`0001000d fffffa80`044e7970 fffffa80`0ad4e9d8 fffffa80`0ad4e9d8 fffffa80`0438fbb0 fffffa80`0ad4e9d0 fffffa80`044e79a0 00000000`0001000e fffffa80`044e79a0 fffffa80`0ad4e8f8 fffffa80`0ad4e8f8 fffffa80`0438fbb0 fffffa80`0ad4e8f0 fffffa80`044e79d0 00000000`0001000f fffffa80`044e79d0 fffffa80`0a521e18 fffffa80`0a521e18 fffffa80`0438fbb0 fffffa80`0a521e10 fffffa80`044e7a00 00000000`00010010 fffffa80`044e7a00 fffffa80`0438ccd8 fffffa80`0438ccd8 fffffa80`0438fbb0 fffffa80`0438ccd0 fffffa80`044e7a30 00000000`00010011 fffffa80`044e7a30 fffffa80`04389608 fffffa80`04389608 fffffa80`0438fbb0 fffffa80`04389600 fffffa80`044e76d0 fffffa60`04010012 2 quadwords at virtual address fffffa80'044e7878 are zeroed - this is the root of the bugcheck, the memory corruption. Looking at the surrounding data, we can guess what should have been here (take a look at the far right column to spot the pattern): 00000000`00010008 fffffa80`043851a8 So, this leads us to the conclusion I posted at the top - "something" corrupted this 16-byte block of data by filling it with 0's, and when the data structure was accessed it caused the bugcheck, and what we see in the stack trace is the victim of the corruption. As to how to nail it down to a particular driver that is causing the corruption, I can only suggest to start with the basics: - is there something in common with the scenario of each bugcheck? - remove VMWare (it has plenty of kernel drivers on the host) - check for an update for the Broadcom NIC driver, it is dated Feb 2007 - remove unnecessary kernel drivers (I see wireless, Connexant modem, touchpad, Dritek keyboard drivers)

Are the volumes on the same disk? If so then you're still looking at a dodgy disk, disk controller or driver if it was changed recently. If they are different disks then I would be more inclined to suspect a disk controller issue (again, unles the drivers were changed shortly before the problem began). To be honest, at this point the dump can't tell you much - except that the disk was physically available to create the dump file itself on C: in raw mode (i.e. not using the disk driver) - at this point you'd be needing to do a live debug to catch the bugcheck and see the state of the system from the kernel's perspective (not a layman job, plus not many people can afford the downtime of the server).

Look into "simple file sharing" and try disabling it on the machine you are connecting from and getting the error.

The virtualization in Vista is how some (typically legacy) applications are "dummied" into thinking they are creating & working with files in protected areas - such as %systemroot%. Vista has a lot more granular security around services, processes, logon sessions and files on disk - some people don't like this "lack of control" or the fact that a system user account has exclusive access to some folders and change the permissions/owners (making it an unsupported scenario). An application wants to create a config.ini file in %systemroot%, but is run by a regular user and not elevated - access would be denied, application would probably fall over or do something unexpected due to bad design. By virtualizing the process, the application thinks it is writing to %systemroot% (C:\Windows) but is in fact having its I/O redirected silently by the kernel - so it gets "success" reported by creating the file, and similarly reading the data back works too. So the first description you mentioned was the closest to the truth. In Task Manager you can see which processes are virtualized and change the virtualization status of a running process. Working example to prove the concept: Open a cmd prompt (not elevated!) and enter the following commands: cd \Windows copy con testvirt.txt Enter some random text and then press enter Result: "Access is denied." Start Task Manager and right-click the cmd.exe process on the Processes tab, click the Virtualization option then click Yes. Now go back to your command prompt window and repeat the above actions - this time no "Access is denied" message appears, so press CTRL-Z and enter to create the file on disk. Open an Explorer window and browse into your C:\Windows folder, look for testvirt.txt.... it doesn't exist (as explorer.exe is not being virtualized). The file is really present in C:\Users\username\Appdata\Local\VirtualStore\Windows - a per-user virtual store for a protected folder. Log on as a different user, repeat the above test using different random text - the file does not appear to exist as this user has not created one, they are distinct.

Highlighting & commenting the interesting bits from the !analyze and !vm outputs... Facts: The Memory Manager tried to read from page file number 1, at offset 00f1a000 and failed with the result "device which does not exist was specified". Theory: I'm going to guess that the page file numbering starts at 0, so page file number 1 is actually the file on the D: volume. The error code isn't "bad block" which would indicate a disk corruption, it is saying that the disk entirely is no longer present. Follow-up: 1. Is D: a partition on the same physical disk as C:, or a separate disk? > The same physical disk would imply C: would have vanished too 2. Is the page file number always the same? > If so, volume D: is looking a bit shaky - consider removing the page file from D: to see if you gain stability Side Note: If the status code had implied "bad data" then I would check if the offset into the page file is the same every time which would imply a localized disk corruption - if it isn't the same offset then it could indicate a failing disk or disk controller.

"ERROR_CODE: (NTSTATUS) 0xc000000e - A device which does not exist was specified. DISK_HARDWARE_ERROR: There was error with disk hardware" Kernel stack inpage error - the OS wanted to copy a section of virtual memory from a page file into physical memory, but the disk was suddenly "not there". On which volumes do you have the pagefile set? Arg3: 00000001, page file number (Hint: use the command !vm in the debugger and see the summary at the top) It may be occurring only when trying to access the page file on a volume other than the boot volume (the fact that you created a dump successfully is an indication the boot volume is probably still available)... Check the version of your SCSI controller driver, is there an update available for it?