cluberti

I need the .dmp files, not just the log.

Dino is a personal friend of mine, and while he did take a new job recently that has basically taken all of his time (wherever he may work, I will not divulge someone else's employer without their OK), I'd suggest not jumping to conclusions that the products are "dead" until he says otherwise. As far as I know, they're still "alive", and I have seen no indications otherwise.

Well, this is why we check - looks can be deceiving. It does look like your video driver (well, actually a supporting file, but part of the driver set) is indeed at fault: 1: kd> !thread GetPointerFromAddress: unable to read from fffff800011b2758 THREAD fffffadf34ce9040 Cid 1020.036c Teb: 00000000fffdb000 Win32Thread: fffffa8006ce99b0 RUNNING on processor 1 IRP List: Unable to read nt!_IRP @ fffffadf35332cf0 Not impersonating GetUlongFromAddress: unable to read from fffff800011d1908 Owning Process fffffadf34a532a0 Image: EverQuest2.exe Attached Process N/A Image: N/A fffff78000000000: Unable to get shared data Wait Start TickCount 163757 Context Switch Count 1011787 LargeStack ReadMemory error: Cannot get nt!KeMaximumIncrement value. UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x0000000000c46ede Start Address 0x0000000077d59680 Stack Init fffffadf17598e00 Current fffffadf17597e30 Base fffffadf17599000 Limit fffffadf1758f000 Call 0 Priority 8 BasePriority 8 PriorityDecrement 0 Child-SP RetAddr : Args to Child : Call Site fffffadf`17596f58 fffff800`0102e5b4 : 00000000`0000003b 00000000`c0000005 fffff97f`ff51cdef fffffadf`17597910 : nt!KeBugCheckEx fffffadf`17596f60 fffff800`0102e03b : 00000000`00000000 fffff800`010486c4 fffffadf`17597220 00000000`00000000 : nt!KiBugCheckDispatch+0x74 fffffadf`175970e0 fffff800`0105492d : fffffadf`17597f00 00000000`17597910 00000000`00000000 00000000`00000000 : nt!KiSystemServiceHandler+0x7b fffffadf`17597120 fffff800`01054ec3 : fffffadf`175975e4 fffffadf`17598bb0 00000000`00000000 00000000`17597910 : nt!RtlpExecuteHandlerForException+0xd fffffadf`17597150 fffff800`0100b901 : fffffadf`00000000 fffffadf`17597910 fffffadf`17597f00 fffffadf`17598010 : nt!RtlDispatchException+0x2c0 fffffadf`17597810 fffff800`0102e6af : fffffadf`17597f00 fffffa80`07baa598 fffffadf`17597f90 00000000`00010600 : nt!KiDispatchException+0xd9 fffffadf`17597e10 fffff800`0102d30d : fffffadf`175984f0 fffffadf`17598280 fffffadf`00001f80 fffff97f`ff5288e7 : nt!KiExceptionExit fffffadf`17597f90 fffff97f`ff51cdef : fffffa80`017e6268 00000000`00000000 fffffa80`014ced00 fffffa80`00000004 : nt!KiGeneralProtectionFault+0xcd (TrapFrame @ fffffadf`17597f90) fffffadf`17598120 fffffa80`017e6268 : 00000000`00000000 fffffa80`014ced00 fffffa80`00000004 fffffa80`017e6268 : ati2cqag+0xcdef fffffadf`17598128 00000000`00000000 : fffffa80`014ced00 fffffa80`00000004 fffffa80`017e6268 fffff97f`ff51a9d6 : 0xfffffa80`017e6268 1: kd> lmvm ati2cqag start end module name fffff97f`ff510000 fffff97f`ff5ca000 ati2cqag T (no symbols) Loaded symbol image file: ati2cqag.dll Image path: ati2cqag.dll Image name: ati2cqag.dll Timestamp: Mon Dec 01 14:48:11 2008 (49343F7B) CheckSum: 000B984C ImageSize: 000BA000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 All of the GPFs and Timer Expiry dumps you have all come back to the ATI driver not clearing a timer before freeing it's pool allocation, causing the DPC issue (which generates a protection fault on timer expiry, causing the bulk of the crash dumps you are seeing). Time to go to ATI/AMD to get a driver that has this fixed, it seems. Good luck.

Both.

0: kd> kb RetAddr : Args to Child : Call Site fffff800`0102e5b4 : 00000000`0000000a fffffadf`d8eb1110 00000000`0000000c 00000000`00000000 : nt!KeBugCheckEx fffff800`0102d547 : fffffadf`8cc54fc0 00000000`00000000 fffffadf`989b8d00 00000000`ffffffff : nt!KiBugCheckDispatch+0x74 fffff800`01028e9a : fffff800`011b2480 fffff800`00117c50 fffff800`0083f480 fffff800`0083f480 : nt!KiPageFault+0x207 fffff800`01028670 : 00000000`00000010 00000000`00000202 00000000`003562b4 00000000`00000018 : nt!KiTimerExpiration+0x1a4 fffff800`01067b90 : fffff800`011b0180 fffff800`011b0180 00000000`0005ffd4 fffff800`011b4500 : nt!KiRetireDpcList+0xae fffff800`014141d1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x50 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemStartup+0x1bf 0: kd> !pcr Cannot get PRCB address 0: kd> !frozen Processor states: 0 : Current Cannot get PRCB address for processor 1 Unless you can upload a *complete* memory dump (4GB - you'll probably want to zip it before uploading it anywhere) I can't tell you which driver didn't release it's lock on a timer in nonpaged pool before exiting, causing the computer to crash later when the DPC List is being retired (the problem is very, very likely a driver issue, not a hardware issue). No, you have a 2GB dump for a machine with 4GB - probably 50% of the necessary information to walk a dump is missing. Again, you need a *complete* memory dump (your paging file needs to be at least 4GB+50MB for this to work) to get a valid dump file.

Bug check 0x1E: Bug Check 0x1E: KMODE_EXCEPTION_NOT_HANDLED The KMODE_EXCEPTION_NOT_HANDLED bug check has a value of 0x0000001E. This indicates that a kernel-mode program generated an exception which the error handler did not catch. Parameters The following parameters are displayed on the blue screen. Parameter Description 1 The exception code that was not handled 2 The address at which the exception occurred 3 Parameter 0 of the exception 4 Parameter 1 of the exception Cause This is a very common bug check. To interpret it, you must identify which exception was generated. Common exception codes include: 0x80000002: STATUS_DATATYPE_MISALIGNMENT An unaligned data reference was encountered. 0x80000003: STATUS_BREAKPOINT A breakpoint or ASSERT was encountered when no kernel debugger was attached to the system. 0xC0000005: STATUS_ACCESS_VIOLATION A memory access violation occurred. (Parameter 4 of the bug check is the address that the driver attempted to access.) For a complete list of exception codes, see the ntstatus.h file located in the inc directory of the Windows Driver Kit. Bug check 0x24: Bug Check 0x24: NTFS_FILE_SYSTEM The NTFS_FILE_SYSTEM bug check has a value of 0x00000024. This indicates a problem occurred in ntfs.sys, the driver file that allows the system to read and write to NTFS drives. Parameters The following parameters are displayed on the blue screen. Parameter Description 1 Specifies source file and line number information. The high 16 bits (the first four hexadecimal digits after the "0x") identify the source file by its identifier number. The low 16 bits identify the source line in the file where the bug check occurred. 2 If NtfsExceptionFilter is on the stack, this parameter specifies the address of the exception record. 3 If NtfsExceptionFilter is on the stack, this parameter specifies the address of the context record. 4 Reserved Cause One possible cause of this bug check is disk corruption. Corruption in the NTFS file system or bad blocks (sectors) on the hard disk can induce this error. Corrupted SCSI and IDE drivers can also adversely affect the system's ability to read and write to disk, thus causing the error. Another possible cause is depletion of nonpaged pool memory. If the nonpaged pool memory is completely depleted, this error can stop the system. However, during the indexing process, if the amount of available nonpaged pool memory is very low, another kernel-mode driver requiring nonpaged pool memory can also trigger this error. Bug check 0x3b: Bug Check 0x3B: SYSTEM_SERVICE_EXCEPTION The SYSTEM_SERVICE_EXCEPTION bug check has a value of 0x0000003B. This indicates that an exception happened while executing a routine that transitions from non-privileged code to privileged code. Parameters The following parameters are displayed on the blue screen. Parameter Description 1 The exception that caused the bug check 2 The address of the exception record for the exception that caused the bug check 3 The address of the context record for the exception that caused the bug check 4 0 Cause This error has been linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code. Bug check 0xd3: Bug Check 0xD3: DRIVER_PORTION_MUST_BE_NONPAGED The DRIVER_PORTION_MUST_BE_NONPAGED bug check has a value of 0x000000D3. This indicates that the system attempted to access pageable memory at a process IRQL that was too high. Parameters The following parameters are displayed on the blue screen. Parameter Description 1 Memory referenced 2 IRQL at time of reference 3 0: Read 1: Write 4 Address that referenced memory If the driver responsible for the error can be identified, its name is printed on the blue screen and stored in memory at the location (PUNICODE_STRING) KiBugCheckDriver. Cause This bug check is usually caused by drivers that have incorrectly marked their own code or data as pageable. If you want more than that, you'll have to get memory dumps of the actual problems uploaded somewhere for us to look at. However, seeing that these are generally all 0x1e, 0x24, and 0x3b bugchecks, I'd think this could be a filter driver installed by a firewall, or antivirus, or even potentially malicious code running in kernel. It *could* be a video driver issue, but that would be a pretty bizzare string of bugchecks from a video driver (again, it's possible, but probability is low). I'd make sure the system was clean, any antivirus software was updated to the latest version, and the same with firewall software (and any virtual CD drive software you may have on the box as well, if any exist - this seems to potentially be a driver issue that can access the disk subsystem, so that would include antivirus, firewall, virtual drive software, etc).

Not to pile on with new links, but one must learn to search, as it will save one time in the future with questions like this.

Wonder if you could get your hands on one of the older nvidia driver builds - never heard of this with their older betas.

http://msdn.microsoft.com/en-us/library/aa366778.aspx This has been discussed ad-nauseam. It was originally done because certain drivers would have an issue with the larger address space and load locations on 32bit systems with the PAE kernel. Since Vista was originally supposed to be the last x86 Windows client, I don't think there was a big push to "fix" x86 clients. With Win7 definitely being the last client to ship with an x86 kernel (2008 R2, aka Win7 server, is already x64-only) I don't see a real need to "fix" this as most desktop users probably don't need more than 3GB of RAM for their daily tasks anyway, and those that do have likely migrated to x64 (XP, Vista, or Win7) desktops anyway. Technically an x64 OS can access 16 exabytes of RAM, but are we going to start complaining because the limit is artificially capped at 1TB for most architectures?

Ripped from Neowin. Of your 9 posts here, 3 are like this. Either stop plagiarizing, or find yourself banned. At least give credit where credit is due if you're going to rip an editorial from a site.

Can't answer whether or not to do what you're asking, but I can confirm that zone checking is done via urlmon.dll, not browseui or shdocvw.

Rumors are correct, x64 has been around since the alpha versions.

This is already documented on Technet. Is that not what you're looking for?

I was able to get to a few FTP sites, including hp's, from IE8. Sounds like perhaps you have an add-on loaded causing the problem? I'm with CoffeeFiend that we probably need some more info, as I verified on 3 installs (IE8 on XP, IE8 on Vista, and IE8 on Win7 RC) that it works, so IE8 is capable.

Well, considering all versions of Windows since XP don't actually need to use the browser for WU anymore (and since Vista in 2006, you cannot at all), why spend the money to develop and test an x64 control that virtually no one will actually use? Until Vista, more people used Win98 than used an x64 version of Windows. Not wanting to pay to develop something no one will use isn't lazy, it's good business sense and is fiscally responsible with basically no effect negatively on the market. There was never a need for an x64 version of the WU controls, period. As to this, I agree - until Microsoft forces x64 Windows and deals with the backlash of incompatible apps, there will always be vendors still writing x86-only versions of software. I think x64 Vista and the upcoming Win7 gives Microsoft enough cushion to pull the x86 line off the market in Win8 (which they've said many times they will do, and Win7 is the last Windows to ship with an x86 client version) and force vendors to start writing x64 apps. Most major antivirus, antispyware, and firewall apps now come with x64 versions, and Microsoft finally has an x64 Office version to go along with all the other server and client apps they make x64, so I do truly think Win7 will be the last bastion of x86 - but, as with everything, once a version of Windows ships with an x64-only client, there will still be folks who have x86-only software and they'll be screaming (here and elsewhere) about how Microsoft is breaking their apps unnecessarily, etc.Chicken and egg, indeed, but it's definitely more complex than that.

Yes, but I wouldn't personally do it. Windows has no such feature, although there are third party products that claim to be able to do it. Again, I'd consider it a one-way street. You're using Windows for RAID, so I'm not sure I'd worry about it if you have a good backup strategy anyway, as Windows for RAID instead of a hardware RAID card is not what I'd recommend either, but if you're just testing it should be fine.

2 things - one, you must have a second disk that's at least the same size as the volume you want to mirror, and two, you won't get this to work from within Windows once it's configured on a boot volume, or at least not without configuring the disks to be dynamic disks, as you cannot mirror a basic boot volume once Windows is running, only dynamic disks - this has been a requirement since Windows 2003, and obviously, hardware RAID is preferred to a dynamic disk RAID in Windows.

Correct - because WU uses an activex control which is 32bit only.

And in general, Microsoft has no control over non-Microsoft codecs. Hence why there's an x86 version of WMP on x64, and it's the default - similar to the way x86 IE is the default on x64 Windows, due to controls not under Microsoft's control generally being x86-only.

Technically you don't need to buy media with SP3, as you can integrate the SP3 package onto the SP2 disc (and technically, this is preferable as it allows you to skip the product key screen, which you can't if you slipstream SP3 over RTM media). I fail to see the *need* for a clean source to slip SP3 onto.

Technically yes, but there's some gray area as to where this copy must come from. In general, I believe the law would allow and expect YOU to make the copy from your original media, as it was written that you were allowed to make a copy for backup purposes (implying you made a copy from your media, not download a copy from someone else's).Since this is technically gray area, I'll consider that you have a copy from your own media that you're going to go and make right now, and we'll discuss your copy. Sound good? I know it does. Continue the discussion.

Correct. Pay closer attention to my post. You can get the SP level from the build # in the output - SPBUILD 18000 is SP1, 16386 is RTM (Vista only). However, to get the actual OS version (Server 2008 vs Vista), you will need to parse the DESCRIPTION field.

Pinned.

Straight Vista (depending on x86 vs x64) shouldn't be more than 8 - 9GB, and compressed they can get down under 6GB (the WIM on the x64 Vista DVD is ~3.6GB, for instance). If you're seeing 20GB, you need to make sure you're compressing the WIM when you imagex the drive, and also you might want to test just Vista, and Vista + your software load to see where that "space" is going.

Here's two questions to think about - 1, did they tell you *why* they thought it was a Vista problem? 2, have you tried logging in and running Word as administrator (right - click the Word icon and choose the "Run as Administrator" option, which you may already be aware of) to see if it's not a permissions issue from the lower-integrity Word process trying to run an add-in that wants to speak to the COM subsystem that may require higher-integrity levels?