P2V system High CPU utilization on csrss.exe process

[ltfields]

Here's the backstory of this particular P2V migration:

Physical server was a Dell PE750 with a single proc and Hyper-threading turned on. We used VMware converter to P2V it onto our ESX 3 cluster and it came across with 2 vCPUs. We only want it to run 1 vCPU, so I installed Vmtools, and set the boot.ini to use the /numproc=1 option. Then I went into the VM settings and set the vCPU to be 1.

When I powered the box back up, the csrss.exe process jumped to 100% cpu utilization and has been like that for almost a week now. I've been digging around and I would prefer not to try and change the HAL from multi to uniproc if I can help it, but does anyone have thoughts on why the /numproc works on 6 other PE750s we virtualized but not this one?

Thanks in Advance...

[cheeko]

I think your best bet here is to switch over to the uniproc HAL, as your VM seems to be confused.

The /numproc=1 is not necessary.

Take a snapshot, change the HAL, see if it works and delete the Snapshot or go back.

[esiebert7625]

I'd change the HAL on it...

If you change from a multi-processor system to a uni-processor system you need to manually change the HAL on the Windows server after the conversion. To do this go into Device Manager after the machine first boots and discovers it's new hardware and then click on Computer then right-click on the processor and select Update Driver. Then select Install from specific location and then Don't search I will choose the driver to install. Then select show All compatible hardware and select the appropriate processor. For example, if you went from a dual cpu to a single cpu then select ACPI uni-processor PC instead of ACPI multi-processor PC. You will need to reboot once you change this. To verify what HAL you are using you right-click your hal.dll in c:\windows\system32 and select the Version tab and select Internal Name and it should say halmacpi.dll for multi-processor acpi and halacpi.dll for uni-processor acpi

[ltfields]

I snapped the VM into our lab environment and changed the HAL to uni-processor successfully but no dice, csrss.exe is still eating up 100% cpu. Anything else I can look at to troubleshoot it?

[esiebert7625]

You might first run a virus/spyware check on the VM. Next try running Process Explorer or Process Monitor from sysinternals to further isolate the cause. You can also use Kernrate to debug. It could also be caused by a corrupt user profile as a result of the P2V.

You can also try removing old non-present hardware from the VM and make sure you un-install any hardware specific drivers/software.

Remove non-present devices from converted system - http://www.oreilly.com/catalog/winxphks2/chapter/hack116.pdf

http://support.microsoft.com/kb/315539

Kernrate viewer - http://www.microsoft.com/downloads/details.aspx?familyid=d6e95259-8d9d-4c22-89c4-fad382eddcd1&displa...

Sysinternals utilities - http://www.microsoft.com/technet/sysinternals/default.mspx

Also check these links...

http://support.microsoft.com/kb/555021

http://forums.pcworld.co.nz/archive/index.php/t-53144.html

What should I do after I successfully convert my virtual machine?

If you change from a multi-processor system to a uni-processor system you need to manually change the HAL on the Windows server after the conversion. To do this go into Device Manager after the machine first boots and discovers it's new hardware and then click on Computer then right-click on the processor and select Update Driver. Then select Install from specific location and then Don't search I will choose the driver to install. Then select show All compatible hardware and select the appropriate processor. For example, if you went from a dual cpu to a single cpu then select ACPI uni-processor PC instead of ACPI multi-processor PC. You will need to reboot once you change this. To verify what HAL you are using you right-click your hal.dll in c:\windows\system32 and select the Version tab and select Internal Name and it should say halmacpi.dll for multi-processor acpi and halacpi.dll for uni-processor acpi.

Next clean up all the non-present hardware after the P2V conversion. To do this go to a CMD prompt and type SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 and then in the same window type DEVMGMT.MSC and then select Show Hidden Devices. Delete any old grayed out hardware.

Next remove any vendor specific applications/drivers. For example on a HP server you should go to Add/Remove programs and remove any HP management agents, survey utility, array config utility, version control agent, etc. Also check your NIC and make sure there are no vendor specific drivers there (ie. teaming). Check the Services to see if all there is anything vendor specific related there and disable any services that are.

fyi..if you find these posts helpful, please award points using the Helpful/Correct buttons...thanks

[ltfields]

I've made some progress in this, as I believe the high CPU is being caused by an old instance of SQL 2000 on the box that is damaged. I hadn't noticed the SQL instance because it looks like it was only partially installed at some point (this box hasn't been touched in about a year and was relying on our SQL cluster for it's databases). I'm setting up a partial replica of our SQL cluster in my lab to see if I can repair the SQL instance enough to get the CPU down...

thanks for all the help so far!

[esiebert7625]

I've seen Converter corrupt some files on several occasions. I'd run Chkdsk on the new VM and it would find a bunch of damaged files. Thats why it is preferable to shutdown everything you can while migrating hot.

[ltfields]

I ran Chkdsk and it didn't find any problems, however after running it, the CPU is down to about 60% utilization. I think once I can get the SQL cleared up I'll be in good shape, but we'll see.