I have a Windows Server 2003 Standard SP2 server, on which svchost.exe crashes multiple times a day. Windows Updates are nearly entirely up to date - I think there's only 4 outstanding. When svchost.exe crashes, it takes out a pile of core Windows services - Server, Task Scheduler, Browser, Netman, and more. Visual Studio happens to be installed on this box, so whenever svchost.exe crashes, the VS Just-In-Time Debugger pops up and says "An unhandled win32 exception has occurred in svchost.exe [PID#]". When I click ok on the VS JIT Debugger window, the services crash. I then restart them straight away and the server keeps running for a while. I know this is classic virus behaviour, but the server has active AV that is fully up to date. I have run full scans with the installed AV app and 2 other AV apps. Nothing found. I have run System File Checker multiple times. I have Process Explorer on the server and can see the PID of the svchost.exe instance in the list. In ProcExp if I open the PID in question and hit Verify, it reports as "(Verified) Microsoft Windows Component Publisher". All the Services that crash are listed on the Services tab of the PID in question in ProcExp. At the moment my only thought is to reinstall SP2 and re-apply all the Windows Updates. Any other ideas?

At the moment my only thought is to reinstall SP2 and re-apply all the Windows Updates. Any other ideas? Yes, while you state you're running an AV, something may still have been able to slip through and if this is the case, it may now keep itself hidden from the AV; so, given that you're wasting time due to those reboots, I think you may spend some time by performing an "offline scan" For such a purpose, download this Microsoft tool (using a separate, trusted machine) and proceed running it and burning the "boot CD" at that point, use the CD to boot the server and proceed with a full scan/clean of the box; that will, at least, help you ensuring that the server isn't infected by some kind of malware/rootkit and may also help tracking the cause of the issue Once the above test will be completed and given that the box will result clean, we may go on trying to investigate the causes of the crash.

Hi, An Offline virus scanning is necessary. Meanwhile, if there is no virus found, it will be a system crash/BSOD issue. It is recommanded to contact Microsoft technet support team for such issue as it is difficult to troubleshoot through forum.TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

An Offline virus scanning is necessary. Which is exactly what I recommended :) see, if the system got infected by some kind of "rootkit", such a critter may as well be hiding itself really well by hooking a number of kernel calls, this in turn means that whatever attempt of discovering it using the infected operating system will fail; the only real way to detect such kind of malware, as I (and you) wrote, is to use an offline scanner (like the Microsoft System Sweeper) to boot the system without activating the "suspect" OS; this way the malware won't be active and it may/will be possible to detect and remove it Meanwhile, if there is no virus found, it will be a system crash/BSOD issue. It is recommanded to contact Microsoft technet support team for such issue as it is difficult to troubleshoot through forum. Before going that way we'll need to ensure that the system isn't infected by some malware, otherwise, any kind of recovery action (sfc, restoring...) will probably fail since the malware may then immediately reinfect the system and cause the crashes again.

I tried to use Microsoft System Sweeper, but it gave an error on boot. The software is only beta, so I didn't bother troubleshooting it. This server is actually a VM. I cloned the virtual hard disks, and mounted them a secondary disks on another non-production VM. I then virus scanned the cloned disks...and they came back clean. I might try another AV scanner just in case, but at this stage its not looking to be a virus.

I tried to use Microsoft System Sweeper, but it gave an error on boot. The software is only beta, so I didn't bother troubleshooting it. This server is actually a VM. I cloned the virtual hard disks, and mounted them a secondary disks on another non-production VM. I then virus scanned the cloned disks...and they came back clean. I might try another AV scanner just in case, but at this stage its not looking to be a virus. Ok, let's assume the system (ok the VM) is clean; I think that a first step may be running an "sfc /scannow" to ensure the system files are ok and then, if the scan will replace some file, monitor the system to see if the problem was solved; if that isn't the case and given that the crash happens in svchost which is a "services host", you may try identifying the instance of svchost which crashes and find out which services are running under it by double clicking the svchost instance in process explorer and selecting the services tab; at that point, you may try (temporarily) stopping/disabling whatever not-required (for system to work) service and checking if the problem will be solved; if that's the case, you may then go back re-enabling/starting one service at a time until you'll find the culprit; at that point, you may be able to reinstall/update that software so possibly solving your issue Notice that, a workaround (not a solution) to avoid that a crashing service may in turn crash svchost and bring down some core services so causing the system to crash may be moving the "unstable" service(s) to a separate instance of svchost which will only run them; this way, in case of crash, only those services (and not the whole system) will go "down"; to do so, once identified the "suspicious" services, you may use the "sc" command this way SC Config Servicename Type= own where "Servicename" will be the name of the desired service (notice that the space between the equal sign and "own" is needed !)

Thanks for the feedback ObiWan, but I did already mention in my original post that I have run sfc a few times now :) I've also looked at the services tab of the crashing instance of svchost.exe in procexp, and it has a pile of core Windows services attached to it. FYI, they are: AeLookupSvc BITS Browser CryptSvc dmserver EventSystem helpsvc lanmanserver lanmanworkstation Netman Nla Schedule seclogon SENS ShellHWDetection TrkWks winmgmt wuauserv and as mentioned previously, when I click ok on the JIT Debugger window reporting the crash of svchost.exe, all these services stop and have to be restarted.

Thanks for the feedback ObiWan, but I did already mention in my original post that I have run sfc a few times now :) I've also looked at the services tab of the crashing instance of svchost.exe in procexp, and it has a pile of core Windows services attached to it. FYI, they are: [...] and as mentioned previously, when I click ok on the JIT Debugger window reporting the crash of svchost.exe, all these services stop and have to be restarted. Ok, given the above, I think you may start by reading this document and try splitting those services sharing that instance of svchost so that they'll use their own instance; done that, try replicating the "crash" and check which instance of svchost is crashing, that will in turn tell you which service is crashing and may help further investigating the issue; notice that once you'll know which service is crashing, you may rollback the other services so that they'll share the same instance of svchost again (so sparing memory/resources) and leave only the "unstable" service alone; then, once the issue will be fixed, you may move back that service to "shared" mode HTH [edit] Notice that before going on with the above, it may be a good idea to create a system restore point so that, in case of issues due to "services splitting" you'll be able to rollback the changes [edit #2] Forgot (sorry, it should have been amongst the first steps); did you check the eventlog to see if it contains any info which may also be useful to help tracking or pinpointing the issue ?