Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a SQL SERVER DB running on a windows server 2008 (VMWare) Yesterday I could not RDP to it so I ended some RDP sessions which were left logged in. This seemed to solve the problem. However last night I learned that the DB was inaccessible and unresponsive to customers. My colleague checked the server but again is unable to create an RDP connection.
He then restarted the server and since it has been fine.

Looking at the CPU Readings of the Server it spiked up to 100% before the original RDP problem .After I ended the extra seeions uit again dropped down to normal levels however before the time of the customer complaint it had rose to 100% again - before it had to be restarted. Is there anyway I can investigate which processes may have caused the problem in the first place. Would there be some kind of memory dump from when it was restarted. I would prefer to find out what is wrong now instead of waiting until it happens again.

share|improve this question
What version of Vmware are you running? There is a knowen KB about Win2008 and ESXi 5.1 and muilty RDP issues causing exactly the behaviour you describe. – t1nt1n Dec 19 '12 at 13:58
Also in the Application log do you see any errors like [ warning] [vmusr:vmtoolsd] Failed registration of app type 2 (Signals) from plugin unity. – t1nt1n Dec 19 '12 at 14:06
Hi t1nt1n could you elaborate on this issue? "There is a knowen KB about Win2008 and ESXi 5.1 " Please and thanks. – Charlie Dec 20 '12 at 12:58

You could enable Full Memory dump ( )

Do not forget to check event log.

share|improve this answer
Didnt crash so dump wasn't written to. Thanks. – Charlie Dec 20 '12 at 12:58

I would first see if there were any DMP files created and check the date the DMP file was created too. You can search your file system for this; use the modified date . Here is an article (there are a few on the net) about how to analyze the DMP file. It sounds daunting at first but if you can find a DMP file on your system drive and open it up, then it does give you some idea of what was happening at the time. The other things to check is log files and the event viewer. Trace back the time when the machine hung and rebooted. Generally speaking in my experience, it usually is a suspect driver of some kind. CHeck you have the latest updates etc.. Using the windbg tools should help you here.. Good skill to have in your tool box too

share|improve this answer
Hi Thanks but nothing in the dump file. It wasn't updated. – Charlie Dec 20 '12 at 10:18
I would do what dr-evil suggested then in case it happens again. You could enable Full Memory dump ( ). The other thought is a that if there is no DMP file, the the OS may not have been able to write to disk at the time of the crash. If that is the case, with a high CPU, is your disk subsystem healthy? – Oli Dec 20 '12 at 10:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.