cluberti

Yes, it does. That bugcheck (a STOP 0xE2) is what generates the dump.

An easier way to see/disable shell extensions is to download and run ShellExView and disable all non-Microsoft items from there, as it is much easier to determine which extension is non-Microsoft (the vendor for each is named in the list).

If you can't do the complete, don't fret - set everything else as needed, and then make the following registry change (reboot required): Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl Value: CrashDumpEnabled Type: REG_DWORD Value: 1 You still won't see complete dump in the GUI, but as long as this is set it will do a complete dump (don't click OK in the GUI after setting this either, or it will change it back to kernel or mini).

Also, until the RCs, it's still running checked code so that will also slow things down quite a bit (these were the same complaints of Vista during beta, before RCs).

Well, no dumps were created, only log files. Also, all the log files match up with running svchost.exe processes in the Process List file, so this captured no crashes. Can you try again and see if it generates any .dmp files next time? You may have to reboot and run the adplus command again.

From the description of the activity, and the fact that the files change as to what it's reading, it's likely that this is being caused by the ReadyBoost and/or Superfetch services. If you stop and disable both of those services, does the problem stop?

Which version of XP is this - home or pro?

Bypassing the EULA on redistributed editions of the powerpoint viewer is actually against the EULA, so you shouldn't be doing this. The user should only get the prompt once.

I'm not sure it should take a long time - my laptop hibernates in about 20 seconds, and even that is slow compared to my desktop (I know, hard disk spindle speeds, etc).

Hmmm, no usermode data (only the ntdll.dll call-in to kernel)... If you could, double-click the svchost.exe line again and tell me what the "Command Line" is? I'm thinking we'll need to break this down to figure it out...

Even though you only have one DC, did you at any point on this network have 2 or more? This error is most commonly seen when FSMO roles are not successfully transferred from one DC to another, and then the role owner was demoted and FSMO roles are then out of whack (and your domain WILL suffer GREATLY). Using ntdsutil to sieze all the FSMO roles (even if it says they're already held by the only DC left on the network) is a good start. Another reason I have seen in my travels is that the IP Security section of the domain in LDAP is missing, which you can check in adsiedit under Domain > System > IP Security (if it's not there, that's bad - your Domain partition will likely be screwed up ). If this is the case, and if you've got another server on the network without major problems you can try importing the HKLM\Software\Policies\Microsoft\Windows\IPSec key into the DC, and/or you can try exporting and importing the IPSec object: - export: ldifde -d "CN=IP Security,CN=System,DC=<domain name>,DC=com" -m -f c:\ipsec.ldf - import: ldifde -i -f ipsec.ldf However, if this really is the only DC, and seizing the FSMO roles don't help, you really will have to rebuild (and you can forget about setting up trusts and moving anything, because the Domain partition is lost and security has failed). Sorry to say it, but you may really indeed be needing a rebuild.

If you set the affinity to one processor or another, this would happen (you can set affinity of a running process via task manager). However, assuming you have not set the affinity of this app to processor #1, then you might want to send their support an email stating that there's a problem in their thread scheduler on your box.

I need you to do what I asked - when the hard disk thrashing is occurring on your box, run process monitor and double-click on one of the svchost.exe lines that seem to happen most frequently, and then click on the "Stack" tab. Please post the output of that.

This is a known issue with no "fix". What happens is the Task Scheduler stores and encrypts user credentials via an encryption key that is generated from a hash of things specific to that installation, including the user's current SID. After you image the box and restore the image, that original key no longer matches the new hash generated for the user, because of the changes made during the imaging process. When this happens, all prior creds on the box no longer match, and usually do not work (I've seen it work before, but it's rare - your scenario is much more common). The fix is to not image a box with Scheduled Tasks, unfortunately.

Right-click IE and choose the "Start Without Add-Ons" option - does the problem still occur there? If so, try running IE from Safe Mode w/ Networking.

Right, and a memory dump at about halfway through the "wait" you are doing would tell us what is happening.

Try this command: cscript C:\debuggers\adplus.vbs -crash -pn svchost.exe -quiet -o C:\adplus (reboot before doing this, just to be safe).

Hard to say for sure yet, but let's get one thing fixed at a time . If it's not the themes service that's crashing the svchost.exe process, we can move it out temporarily to keep aero from dying on you by making a quick registry modification and a file copy: 1. In Windows Explorer, go to C:\Windows\system32\ and right-click the "svchost.exe" file there, and select "copy". Now, right-click an empty area somewhere else inside the C:\Windows\system32 folder and select "paste" to create a file called "copy of svchost.exe" - rename this file "svchost_themes.exe" (without the quotes, obviously). 2. In the registry, browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Themes, and double-click on the "ImagePath" value in the right-hand pane. Modify the current value (which should be "%SystemRoot%\System32\svchost.exe -k netsvcs") so that it reads "%SystemRoot%\System32\svchost_themes.exe -k netsvcs", and click "OK". 3. Reboot - this will move the "Themes" service into it's own svchost.exe process (now called svchost_themes.exe), so that if the svchost.exe process that keeps crashing does crash again, it won't take the Themes service down with it. 4. Now, download and install the debugging tools for windows, and install them to C:\Debuggers (take all other default options, just change the install path). 5. Create the directory C:\adplus. 6. Open a command prompt, and type the following command: cscript adplus.vbs -crash -pn svchost.exe -quiet -o c:\adplus This should attach the cdb.exe debugger to the svchost.exe process(es) running on your machine, and the next time one crashes, it should create data in C:\adplus that can be analyzed to see why the svchost.exe process is crashing.

Hmmmmm - perhaps you could configure the box for a complete dump, and then when the problem occurred again you could dump it while the hard disk is spinning like that?

Not in the classic sense of the word, but Remote Assistance does allow both the remote connector and the host both see the desktop in real time, which is what the OP was looking for.

First, those registry keys point to a Nvidia device (that's who that PCI Vendor is and Device ID), so hard to say if that is normal or not (it may be). However, I would suggest using the process monitor filter to look at only disk traffic (not registry or process traffic) by clicking (to deselect) the "Show Registry Activity" and "Show Process and Thread Activity" buttons on the toolbar, so that only file system activity is displayed. You can also click Tools > File summary to show the summary of files accessed during the period of time process monitor has been analyzing. Second, if an svchost.exe process is the heavy hitter for filesystem activity, and not the search indexer, then disabling the indexing service isn't going to help you (aren't you glad you checked? ). Knowing which svchost.exe is doing the scanning, as well as looking at the stack trace data for that (double-click one of the svchost.exe entries and click the "Stack" tab) should help a bit in narrowing it down, too.

It sounds like the network services svchost.exe process is failing, and the Themes service (which runs in that svchost.exe process) is not restarting properly. When the problem occurs, and you're unable to run in Aero, can you chech to see if the Themes service is running or not?

Disabling the indexing service terminates searchindexer.exe, but it may be better to download and run process monitor to see for sure if it's the search binary hitting your box, or something else entirely.

Sure - almost all hibernation issues with XP (and now Vista) seem to be related to poor network driver support, and those match the symptoms you described. Most cases I've come across or read about on the web related to the actual NIC, but I've heard of a few issues where having the AP or wireless router enabled caused the issue, and replacing the router fixed it as well. You could test if it was your NIC or not by disabling it in device manager and rebooting to see if hibernation behavior changes at all.

Since it is an HP/Compaq, I'd make sure that your array controller is running the latest firmware, and that the drivers you have for the controller in that server is also the latest version (preferrably supported under 2008 as well). All of your troubles thus far come down to driver issues with the array controller, from the symptoms you describe.