Link to home
Create AccountLog in
Avatar of fisher_king
fisher_king

asked on

Resource-Exhaustion-Detector Event 2004 on Server 2008R2

I am helping a client with a software upgrade on their server. One of the updates failed and when I tried to re-install it I got an error that the C drive was full. I decided to move the page file to the D drive to free up space - I originally configured it with 800 MB on the C drive and System Managed on the D drive. I did not know it until later today, but that triggered regular Resource-Exhaustion-Detector Event 2004 errors in the System log:

Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: sqlservr.exe (3016) consumed 749858816 bytes, dns.exe (2140) consumed 247664640 bytes, and dsm_om_connsvc64.exe (4860) consumed 220897280 bytes.

It is always the same 3 programs, but none are using a significant amount of space. I have tried moving the page file back to C, making it system managed, static size, and specified range. I have set it to have no page file, deleted the page file, then re-created it more than once. Currently (after deleting the page file), it is set to 800 MB on the C drive and 32-48 GB on the D drive - and I have verified the size and presence of the page files using SpaceSniffer. The server has 32 GB of RAM and 4 x 100 GB SSD in Raid 5. It is used for AD, SQL 2008, and file server.

How can I resolve the issue without re-installing Windows?

Thanks in advance
Avatar of Robin CM
Robin CM
Flag of United Kingdom of Great Britain and Northern Ireland image

SOLUTION
Avatar of Robin CM
Robin CM
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
ASKER CERTIFIED SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of fisher_king
fisher_king

ASKER

I used process monitor, but it did not reveal SQL to be using all the virtual memory - it was only by disabling the service that I discovered the cause.