cluberti

Hard to say, although since Windows gets a good portion of this information from the MFT and the chipset driver/disk controller driver, it's at least possible that the driver didn't complete it's IRP during the delete, or didn't update the MFT, etc. Which a reboot would of course clear... I can (educated) guess with the best of 'em .

Well, aside from your inefficiency at using the command prompt (you could simply type C:\fah\fah.exe -smp from anywhere and have it work, or at least cd \fah and then run fah -smp), you do not need the command prompt as admin, you only need fah.exe to run as admin (by running the cmd as admin you're launching anything from there as an admin, but that's an extra step you don't actually need). I second the runas prompt - if you perhaps wanted to do this in vbscript, there are code samples on the forums that will run a vbscript as administrator (and thus launch anything run by the vbscript as admin). That might work for you as well if you want to tackle it.

This hotfix does not install any files, it just makes registry changes. However, it's branching information does seem to indicate that it does not check for any other hotfixes before installing. Are you sure that you have the same IE files in your %windir%\system32 and %windir%\system32\dllcache folders? For example, do you have 7.x versions (say mshtml.dll) in \system32 and 6.x versions in \system32\dllcache (or vice-versa). I've seen the (failed) integration of Internet Explorer 7 (and some IE hotfixes) cause all kinds of "missing hotfix' grief post-build.

This hotfix does not install any files, it just makes registry changes. However, it's branching information does seem to indicate that it does not check for any other hotfixes before installing. Are you sure that you have the same IE files in your %windir%\system32 and %windir%\system32\dllcache folders? For example, do you have 7.x versions (say mshtml.dll) in \system32 and 6.x versions in \system32\dllcache (or vice-versa). I've seen the (failed) integration of Internet Explorer 7 (and some IE hotfixes) cause all kinds of "missing hotfix' grief post-build.

I have to give some experience as well, similar to the last poster. You cannot have a second DC holding a role that another DC holds, as they are the single master operation roles. However, taking regular backups of your AD and ensuring replication is working properly at all times means you can simply seize the roles if one of these DCs that held a FSMO role were to become unavailable. Worst case you could restore from the backup, but again, if replication is good, a siezure of roles from another DC is all that it should take to come back up again. This is why any cllient that I talk to has multiple DCs, even on smaller domains.

At least some of these are deprecated as of the Visual C 8.0 runtimes (Visual Studio 2005 timeframe), so I'm wondering what kinds of things were installed (or removed) before the problem occurred. APIs don't just "break" .

Happy Birthday to you, happy birthday to you......

Knowing that, it's more likely you should consider backing up your data and uninstalling/reinstalling the application (or removing it entirely if you don't use it) just in case. If it continues, then contact the vendor.

The error is saying that the eQuality agent dll file (wwts_32.dll) running inside the eQuality service module (captureservice.exe) tried to read from a VIRTUAL memory address of 0x00000014, and failed. I know this will fail because the first 64K of any process space is marked PAGE_NOACCESS, and there should NEVER be any accesses in this region (anything requesting virtual memory at 0x00010000 or below is going to crash with this exact error message). Note that this kind of error would indicate poor software design, but not a hardware problem. I'd contact Witness Systems and see what they say, or if there's an upgraded version that doesn't have the problem, etc. If this was a Microsoft application crashing we could help you more (Microsoft makes certain symbol information public, allowing people to debug their applications to some extent), but this is a Witness Systems module in a Witness Systems application, so the error message is about all we'll be able to tell you from a dump (which we can already see in the screen shot). Unfortunately, you'll have to contact them about this, we won't really be able to be of much service to you. For reference, here is a basic debug of the address layout in any x86 process running on Windows, and will illustrate why an application making a request for data at 0x00000014 will fail: 0:000> !address 00000000 : 00000000 - 00010000 // 0x00000014 falls within this range - note it's PAGE_NOACCESS Type 00000000 Protect 00000001 PAGE_NOACCESS State 00010000 MEM_FREE Usage RegionUsageFree 0:000> ? 00010000 Evaluate expression: 65536 = 00010000 0:000> ? 00000014 Evaluate expression: 20 = 00000014

Not sure, but I would suggest enabling logon/logoff, process, and security auditing - it should tell you why the user was logged off.

Can you post me some links that explain these limitations and features? The limitation isn't in the NTFS filesystem itself (it can have as long a directory depth as you'd like), but most apps will balk at a specific limit (even the Windows properties dialog will balk working with folders that are a certain number of characters long for their strings). I guess I should try to be more concise when I post . Anyway, what I was getting at is that you could be having an issue where Ghost is failing to parse a tree down to a file, or, perhaps running out of kernel pool (thus a lack of PTEs to allocate new data). This does seem odd though, in many ways.

If SP1 was installed and not trying to prop up the RTM version, these issues would not even be issues to begin with.

I'm not sure disabling services makes Vista run any "better", but it should help a little with the startup. However, note that Vista startup is largely asynchronous (whereas 2000 was entirely synchronous, and XP was mostly a synchronous boot with some asynchronous services and drivers). Since Vista is a mostly asynchronous boot process, far more than XP was, reducing boot time by disabling services or drivers won't yeild as much of the same benefit as it would with previous versions. As always, YMMV and the underlying hardware is going to be far more important in the boot process than what you load - if you have older, slower hardware (esp CPU), then yes this will help more than if you have a newer (especially multi-core) machine.

The biggest difference in cost between a 30" monitor and a 42" LCD (for instance) is panel quality and pixel pitch. Most larger LCDs will carry a pixel pitch above .3mm, some even as high as .4 or .5mm. Your *average* 30" PC monitor will be under .29mm, some far lower. The smaller the number, the greater the resolution and better the picture. Sure the 42" will look good from 5ft away or greater (and that may be what you want, so go for it) but unless you get an HDTV with a pixel pitch under .3mm, you will not have as good a picture as you would with a PC LCD (which was meant to be looked at closely, and provide hopefully crisp text and images at closer distances). It's one of the reasons PC monitors can support resolutions higher than 1900x1080 or 1200 (1080i/1080p), like 2560x1600 - it's the pixel pitch (mostly) that allows this, and you won't get something "good" enough with a panel designed for a TV. Which is why a 42" LCD HDTV can retail for ~$1,500USD and a 30" LCD monitor for a PC is $2K or more - it's NOT random .

So, is session expiration set or is it not? It is a somewhat frustrating problem, because it'll happen whilst I am posting a response, say. I get an error that I'm not logged in, and I have to log back in and paste my response (I now know to copy and paste EVERYTHING before hitting "reply", just in case!).

The only thing I would think of is Ghost is hitting a limitation of it's file name depth (too many subfolders), as NTFS has this limitation as well. However, size shouldn't be a problem, although you might want to make sure you reboot before you come to any conclusions. Running out of paged pool memory (you'll see SRV/2020 errors in your system log, with maybe 333 errors as well) can cause these exact symptoms, as you can run into a situation where you can't create enough PTE pool allocations to write the file chunks out.

Is this RRAS, or ISA server?

Agreed. Thankfully, on most laptops (and this one too), the optical drives are removable (Removal and replacement procedures > Component replacement procedures > Optical drive). I'd start by removing the drive and seeing if anything changes.

If you run "route PRINT" from one of the main computers on either network, do you see any route listed to the "other" network? I'm guessing no, but just want to check before going further. Unless you have a router (or configure static routes), none of the machines behind the VPN servers will know magically how to get to the other side. And yes, if you want these VPN servers to also do routing, you should consider a second NIC for each.

Mini100308_01.dmp // The atapi driver is scanning the port for a hard disk to service the work item pending: 0: kd> kb ChildEBP RetAddr Args to Child ba50fbb0 80515b72 0000007a c05cf000 c000000e nt!KeBugCheckEx+0x1b ba50fbe0 805166df 81dbbd30 c05cf000 b9e0050c nt!MiWaitForInPageComplete+0x1ca ba50fc60 80520239 c05cf000 b9e0050c c05cf000 nt!MiDispatchFault+0x2c1 ba50fccc 80544578 00000008 b9e0050c 00000000 nt!MmAccessFault+0x877 ba50fccc b9e0050c 00000008 b9e0050c 00000000 nt!_KiTrap0E+0xd0 ba50fd54 b9e02e29 8a4fd0e8 8a5bf478 8a4fd030 atapi!IdePortScanBus ba50fd68 80576ad5 8a4fd030 8a5c1060 8056485c atapi!ChannelQueryBusRelation+0x2f ba50fd7c 8053876d 8a5bf478 00000000 8a5ad020 nt!IopProcessWorkItem+0x13 ba50fdac 805cff64 8a5bf478 00000000 00000000 nt!ExpWorkerThread+0xef ba50fddc 805460de 8053867e 00000001 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 // This tells us the PTE that will be used, and the pointer it is looking to gather memory from: 0: kd> .frame 1 01 ba50fbe0 805166df nt!MiWaitForInPageComplete+0x1ca // The PTE is valid...: 0: kd> dc 0xc05cf000 c05cf000 34354860 00000000 00000060 0000012e `H54....`....... c05cf010 0a7ee121 00000000 0a7ef121 00000000 !.~.....!.~..... c05cf020 0a7f0121 00000000 0a7f1121 00000000 !.......!....... c05cf030 0a7f2121 00000000 0a7f3963 00000000 !!......c9...... c05cf040 00000000 00000000 00000000 00000000 ................ c05cf050 00000000 00000000 7f523963 00000000 ........c9R..... c05cf060 7f524121 00000000 7f525121 00000000 !AR.....!QR..... c05cf070 7f526121 00000000 7f527121 00000000 !aR.....!qR..... // ...but the contents are either invalid or paged out, thus the page in operation: 0: kd> dc 34354860 L1 34354860 ???????? ???? // So why did the box bugcheck: 0: kd> .bugcheck Bugcheck code 0000007A Arguments c05cf000 c000000e b9e0050c 34354860 0: kd> !error c0000000e Error code: (Win32) 0xe (14) - Not enough storage is available to complete this operation.When a machine bugchecks with a 0x7A, and C000000E is the error code, then this means a hard disk subsystem error (usually the hard disk itself, although I've seen bad motherboard controllers cause this in rare occurrances). See this link for the OCA crash bug attached to dumps of this type. Mini100708_01.dmp // We crashed talking to the HAL, but this is just a victim of a bad driver, it appears: 1: kd> kb ChildEBP RetAddr Args to Child a10f41a0 806ea153 00000cf8 80001090 806f1420 hal!WRITE_PORT_ULONG+0x9 a10f41b4 806e9f0f 806f1420 a10f41d4 a10f4300 hal!HalpPCIWriteUlongType1+0x23 a10f41e8 806ea337 a10f4200 00000002 a10f4300 hal!HalpPCIConfig+0x4d a10f4208 806eb14d a10f422c 00000002 a10f4300 hal!HalpWritePCIConfig+0x2d a10f4298 b9e50ae0 00000000 00000000 00000002 hal!HaliPciInterfaceWriteConfig+0x33 a10f42bc b9e50b74 8a5986f8 00000002 a10f4300 pci!PciReadWriteConfigSpace+0x38 a10f42dc b9e50fcc 8a5cb450 a10f4300 00000090 pci!PciWriteDeviceConfig+0x1e a10f4404 b9e53cbd 8a5cb450 a10f448c 00000090 pci!PciExternalWriteDeviceConfig+0x1ac a10f4428 b9e5034d 8a5cb450 00000000 a10f448c pci!PciWriteDeviceSpace+0x5d a10f4448 b8694212 8a5cb450 00000000 a10f448c pci!PciWriteAgpConfig+0x1d a10f4464 b86b4a11 8a3fe358 00000004 00000000 VIDEOPRT!VideoPortSetBusData+0x3a WARNING: Stack unwind information not available. Following frames may be wrong. a10f4498 b86c838d 8a3fe358 000000ea 00000000 igxpmp32+0xda11 a10f44e8 b869435b 8a3fe358 000000ea 8a1b1000 igxpmp32+0x2138d a10f450c b86a1114 a10f45a4 00000000 8a276b78 VIDEOPRT!pVpGeneralBugcheckHandler+0x61 a10f45cc 804ef18f 89bcc040 88ef7e58 00000000 VIDEOPRT!pVideoPortDispatch+0x4aa a10f45dc bf85a1ae 00000000 00000000 00000000 nt!IopfCallDriver+0x31 a10f460c bf93c989 89bcc040 0023002c 00000000 win32k!GreDeviceIoControl+0x93 a10f4634 bf9608fa 00000000 a10f468c bf805b86 win32k!DrvPrepareForEARecovery+0x26 a10f4654 bf805b2f e2638008 00000000 00000000 win32k!HandleStuckThreadException+0x24 a10f468c bf8baafd e263a018 e5611a90 00000000 win32k!WatchdogDrvCopyBits+0x77 a10f46d4 bf8ba915 bf805b3a a10f477c e263a018 win32k!OffCopyBits+0x7d a10f4788 bf8bab4a e263a018 e5611a90 00000000 win32k!SpBitBlt+0xfc a10f47bc bf80a37e e263a018 e5611a90 00000000 win32k!SpCopyBits+0x27 a10f4850 8054161c e263a008 bf9a5ea8 e1c198f8 win32k!NtGdiBitBlt+0x51c a10f4850 7c90e4f4 e263a008 bf9a5ea8 e1c198f8 nt!KiFastCallEntry+0xfc 0012e630 00000000 00000000 00000000 00000000 0x7c90e4f4 // Looks like an invalid interface pointer was passed...: 1: kd> .trap 0xffffffffa10f4130 ErrCode = 00000000 eax=80001090 ebx=00000090 ecx=00000090 edx=00000cf8 esi=806f1420 edi=a10f422c eip=806ecae1 esp=a10f41a4 ebp=a10f41b4 iopl=0 nv up ei ng nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286 hal!WRITE_PORT_ULONG+0x9: 806ecae1 c20800 ret 8 // ...but checking to be sure...: 1: kd> .bugcheck Bugcheck code 1000008E Arguments 80000004 806ecae1 a10f4130 00000000 // ...and it was: 1: kd> !error 80000004 Error code: (HRESULT) 0x80000004 (2147483652) - No such interface supported // The driver responsible: 1: kd> lmvm igxpmp32 start end module name b86a7000 b8c657a0 igxpmp32 T (no symbols) Loaded symbol image file: igxpmp32.sys Image path: igxpmp32.sys Image name: igxpmp32.sys Timestamp: Fri Jun 27 11:46:47 2008 (48650B67) CheckSum: 005C093F ImageSize: 005BE7A0 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 I think it's important to note that both of these failures are happening at a low level on the system, so having your hardware checked would probably be your best option at this point. I'm not entirely certain of what's going on, because these two aren't seemingly related - however, the first is complaining about your disk hardware, and the second failed when talking to the system hardware via the HAL (hardware abstraction layer .dll), so making sure the hardware is all kosher is probably a good idea.

APPCRASH crashes means that Vista detected that the app crashed - it isn't the root cause, it's just a reporting mechanism. You'll need to get some application dumps of the problem occurring before we can tell you much further.

This one is fairly easy, now that I see it, and needs no more than a !analyze -v: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* KERNEL_DATA_INPAGE_ERROR (7a) The requested page of kernel data could not be read in. Typically caused by a bad block in the paging file or disk controller error. Also see KERNEL_STACK_INPAGE_ERROR. If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185, it means the disk subsystem has experienced a failure. If the error status is 0xC000009A, then it means the request failed because a filesystem failed to make forward progress. Arguments: Arg1: c0712b38, lock type that was held (value 1,2,3, or PTE address) Arg2: c000009c, error status (normally i/o status code) Arg3: e2567028, current process (virtual address for lock type 3, or PTE) Arg4: 2a7f08c0, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address) Debugging Details: ------------------ ERROR_CODE: (NTSTATUS) 0xc000009c - STATUS_DEVICE_DATA_ERROR DISK_HARDWARE_ERROR: There was error with disk hardware BUGCHECK_STR: 0x7a_c000009c CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT PROCESS_NAME: firefox.exe TRAP_FRAME: aa529ac0 -- (.trap 0xffffffffaa529ac0) ErrCode = 00000000 eax=00000800 ebx=00001295 ecx=00000000 edx=e1d40020 esi=00001000 edi=e2563018 eip=bf8374a1 esp=aa529b34 ebp=aa529b58 iopl=0 nv up ei ng nz ac po cy cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010293 win32k!RFONTOBJ::vXlatGlyphArray+0x1d3: bf8374a1 663b54c710 cmp dx,word ptr [edi+eax*8+10h] ds:0023:e2567028=???? Resetting default scope LAST_CONTROL_TRANSFER: from 80512091 to 804f8c3f STACK_TEXT: aa529994 80512091 0000007a c0712b38 c000009c nt!KeBugCheckEx+0x1b aa5299c4 80512bb7 814a5e40 c0712b38 e2567028 nt!MiWaitForInPageComplete+0x1c7 aa529a44 8051c0f8 c0712b38 e2567028 c0712b38 nt!MiDispatchFault+0x2b5 aa529aa8 8053faac 00000000 e2567028 00000000 nt!MmAccessFault+0x7b4 aa529aa8 bf8374a1 00000000 e2567028 00000000 nt!KiTrap0E+0xcc aa529b58 bf85b99b aa529b80 00000001 aa529b74 win32k!RFONTOBJ::vXlatGlyphArray+0x1d3 aa529b78 bf86c156 00000020 00000000 aa529d0c win32k!RFONTOBJ::hgXlat+0x19 aa529c20 bf80829f aa529d0c aa529ca8 e34a5b58 win32k!RFONTOBJ::bRealizeFont+0x1b7 aa529cb0 bf808307 e34a5a38 00000000 00000002 win32k!RFONTOBJ::bInit+0x29a aa529cc8 bf8eccb8 aa529d0c 00000000 00000002 win32k!RFONTOBJ::vInit+0x16 aa529ce4 bf8ecc67 e132b598 70616d63 00000000 win32k!ulGetFontData2+0x17 aa529d04 bf8ecc2a e39bc008 70616d63 00000000 win32k!ulGetFontData+0x48 aa529d48 8053cbc8 180109fe 70616d63 00000000 win32k!NtGdiGetFontData+0x26 aa529d48 7c91eb94 180109fe 70616d63 00000000 nt!KiFastCallEntry+0xf8 WARNING: Frame IP not in any known module. Following frames may be wrong. 180109fe 00000000 00000000 00000000 00000000 0x7c91eb94 STACK_COMMAND: kb FOLLOWUP_IP: win32k!RFONTOBJ::vXlatGlyphArray+1d3 bf8374a1 663b54c710 cmp dx,word ptr [edi+eax*8+10h] SYMBOL_STACK_INDEX: 5 SYMBOL_NAME: win32k!RFONTOBJ::vXlatGlyphArray+1d3 FOLLOWUP_NAME: MachineOwner MODULE_NAME: win32k IMAGE_NAME: win32k.sys DEBUG_FLR_IMAGE_TIMESTAMP: 47e0df7d FAILURE_BUCKET_ID: 0x7a_c000009c_win32k!RFONTOBJ::vXlatGlyphArray+1d3 BUCKET_ID: 0x7a_c000009c_win32k!RFONTOBJ::vXlatGlyphArray+1d3 Followup: MachineOwner It seems that, yes, your disk subsystem reported an error so the bugcheck occurred. I'd say it could be a bad hard disk, so checking is the first thing to do. Making sure the other hardware is working fine is also something I'd suggest as well, just in case.

Hard to say because you didn't configure your symbols before running !analyze -v, but the error code that was reported means this: # for hex 0xc000009c / decimal -1073741668 STATUS_DEVICE_DATA_ERROR ntstatus.h # as an HRESULT: Severity: FAILURE (1), FACILITY_NULL (0x0), Code 0x9c The "device" could be the disk, the controller, anything along the hardware chain. However, I would start checking your hard drive(s) for errors, just to be safe.

No, that's fine. It's going to take some actual debugging to figure out the driver - can you compress and upload those somewhere?

This was also seen in atikmdag back in 2006 (I remember it vividly, still have a dump file) that was fixed when ATI released 8.31.100.2 of that driver (for x64). Note that both caused a page fault by trying to access a memory address that was either paged out or invalid (thus a page fault, thus a 0x50 bugcheck), for clarification on the crash. So, here's *your* callstack, which is awfully close to the *old* callstack I've got (I'll post them both for comparison): // Yours: 0: kd> k ChildEBP RetAddr b56614d4 8052036a nt!KeBugCheckEx+0x1b b566153c 80544578 nt!MmAccessFault+0x9a8 b566153c b5a3b64e nt!_KiTrap0E+0xd0 b56615c8 b5a3bb55 ati2mtag!GetParametersIndirect+0x17 b56615d4 b5a3b0a5 ati2mtag!ProcessCompare+0x20 b5661638 b59e93ea ati2mtag!ParseTable+0x158 b5661660 b59e5b7c ati2mtag!ATOM_ExecuteBIOSTable+0x6d b5661680 b58a4ac8 ati2mtag!CAIL_ExecuteBIOSTable+0x7b b56616a0 b58fdb06 ati2mtag!MCIL_ExecBiosTable+0x46 b56616f4 b5a2c885 ati2mtag!GxoExecBiosTable+0x32 b566171c b5a30cab ati2mtag!bDigitalTransmitterControl+0x91 b5661744 b5d801bd ati2mtag!vRV620LvtmEnableOutput+0x49 b5661774 b5a3a5fb ati2mtag!DigitalEncoderActivate+0x171 b5661794 b595a109 ati2mtag!vGxoEncoderActivate+0x5d b56617b4 b58c4222 ati2mtag!R520DfpSetDisplayOn+0x8f b56617d0 b58c8f21 ati2mtag!vSetDisplayPowerState+0x64 b56617e8 b5d64504 ati2mtag!DALSetDisplayDPMS+0x23 b566183c b5d64ef6 ati2mtag!SetDisplayPowerState+0x1d6 b566185c b5d5b457 ati2mtag!SetNonACPIDisplayPowerState+0x4c b566187c b588e63a ati2mtag!AtiSetPowerState+0x6d b56618e0 804ef18f VIDEOPRT!pVideoPortPowerDispatch+0x476 b56618f0 80526afb nt!IopfCallDriver+0x31 b5661904 80527015 nt!PopPresentIrp+0x57 b5661924 80527185 nt!PoCallDriver+0x195 b5661940 b5892809 nt!PoRequestPowerIrp+0x129 b5661a14 804ef18f VIDEOPRT!pVideoPortDispatch+0xb9f b5661a24 bf85a1ae nt!IopfCallDriver+0x31 b5661a54 bf93e53d win32k!GreDeviceIoControl+0x93 b5661a84 bf88585a win32k!DrvSetMonitorPowerState+0x52 b5661ad4 bf89fd38 win32k!ProcessQueuedMouseEvents+0x3b b5661d30 bf884705 win32k!RawInputThread+0x5b9 b5661d40 bf80110a win32k!xxxCreateSystemThreads+0x60 b5661d54 8054161c win32k!NtUserCallOneParam+0x23 b5661d54 7c90e4f4 nt!KiFastCallEntry+0xfc 006effe0 75b6ba1a ntdll!KiFastSystemCallRet 00000000 f000e816 winsrv!NtUserCallOneParam+0xc WARNING: Frame IP not in any known module. Following frames may be wrong. 00000000 00000000 0xf000e816 // Here's the trap, and the bad math: 0: kd> .trap 0xffffffffb5661554 ErrCode = 00000000 eax=ba187007 ebx=b5661650 ecx=00000002 edx=00000002 esi=b56615ec edi=8970c400 eip=b5a3b64e esp=b56615c8 ebp=b5661638 iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 ati2mtag!GetParametersIndirect+0x17: b5a3b64e 8b0408 mov eax,dword ptr [eax+ecx] ds:0023:ba187009=???????? 0: kd> ? ba187007+00000002 Evaluate expression: -1172803575 = ba187009 // Just to prove it's bad: 0: kd> dc ba187009 L1 ba187009 ???????? // The version and driver you've got, so that you know who / what to point to when talking to AMD: 0: kd> lmvm ati2mtag start end module name b5898000 b5da6000 ati2mtag (pdb symbols) C:\symbols\ati2mtag.pdb\5F422667FF7243918D0A8E909671DA531\ati2mtag.pdb Loaded symbol image file: ati2mtag.sys Image path: \SystemRoot\system32\DRIVERS\ati2mtag.sys Image name: ati2mtag.sys Timestamp: Wed Aug 20 22:17:42 2008 (48ACD046) CheckSum: 00330EE7 ImageSize: 0050E000 File version: 6.14.10.6860 Product version: 6.14.10.6860 File flags: 8 (Mask 3F) Private File OS: 40004 NT Win32 File type: 3.4 Driver File date: 00000000.00000000 Translations: 0000.04b0 CompanyName: ATI Technologies Inc. ProductName: ATI Radeon WindowsNT Miniport Driver InternalName: ati2mtag.sys OriginalFilename: ati2mtag.sys ProductVersion: 6.14.10.6860 FileVersion: 6.14.10.6860 FileDescription: ATI Radeon WindowsNT Miniport Driver LegalCopyright: Copyright (C) 1998-2004 ATI Technologies Inc. // The old one I had from 2006 - it's x64, but it's basically the same as your x86 crash: 0: kd> k ChildEBP RetAddr fffff980`046270d8 fffff800`01854e18 nt!KeBugCheckEx fffff980`046270e0 fffff800`0184cdd9 nt!MmAccessFault+0x137c fffff980`046271e0 fffff980`03c26c12 nt!KiPageFault+0x119 fffff980`04627378 fffff980`03c26ce4 atikmdag!GetParametersIndirect+0x22 fffff980`04627380 fffff980`03c2665b atikmdag!ProcessMove+0x3c fffff980`046273c0 fffff980`03bf18f3 atikmdag!ParseTable+0x1f7 fffff980`04627460 fffff980`03bf1cc7 atikmdag!ATOM_ExecuteBIOSTable+0x6b fffff980`046274c0 fffff980`03bf1d50 atikmdag!ATOM_InitFanCntl+0x57 fffff980`04627510 fffff980`03bf1e24 atikmdag!ATOM_PostVBIOS+0x74 fffff980`04627580 fffff980`03becfe7 atikmdag!ATOM_NoBiosInitializeAdapter+0xc0 fffff980`046275d0 fffff980`03a7e0f5 atikmdag!CAILNoBiosInitializeAdapter+0x6b fffff980`04627610 fffff980`041cf200 atikmdag!AsicInit::InitializeAdapter+0xa1 fffff980`04627710 fffff980`041ec051 atikmdag!AtiStartDevice+0x158 fffff980`046277d0 fffff980`039541fe atikmdag!DlpStartDevice+0x49 fffff980`04627830 fffff980`0394ea72 dxgkrnl!DpiDxgkDdiStartDevice+0x62 fffff980`04627880 fffff980`0394eee2 dxgkrnl!DpiFdoStartAdapter+0x37e fffff980`046279e0 fffff980`039499bf dxgkrnl!DpiFdoStartAdapterThread+0x17a fffff980`04627a70 fffff980`0360f1b2 dxgkrnl!DpiSessionCreateCallback+0x1b fffff980`04627aa0 fffff980`0360f0ea watchdog!SMgrSessionOpen+0x42 fffff980`04627ae0 fffff960`000059b3 watchdog!SMgrNotifySessionChange+0x22 fffff980`04627b20 fffff960`00005d4c win32k!InitializeGreCSRSS+0x23 fffff980`04627be0 fffff800`0184dcf3 win32k!NtUserInitialize+0x13c fffff980`04627c20 000007fe`fd63ca0a nt!KiSystemServiceCopyEnd+0x13 00000000`0032f598 00000000`00000000 0x7fe`fd63ca0a I'd say an email or phone call to AMD/ATI is in order, as it looks like this is still broken in a different driver. Good luck.