During a routine check of a network I prepared to run
dcdiag /c /a /v /f:C:\DCDIAG_AUG11.txt
on a 2003 R2 Server.
I received this error message
“NT5DS has encountered a problem and needs to close. We are sorry for the inconvenience.”
I had never had an issue running DCDIAG before and at first thought it was something with the switches I was using. I received the same error when running dcdiag without any additional switches.
The Event Log had this vague (at the time) error.
The first thought I had is that this may be a time issue. I received some assistance from James Sumerlin who also was suspicious about the possibility of a timing issue. After running the basic time checks we determined that everything on the DC, and the other servers, where in fact, in sync.
James brought up the issue of Deployment Execution Prevention (DEP) as a possible cause. I have never run into an issue such as this before, but this is a new environment for me and it sounded like a plausible cause.
I would not be able to reboot the DC – required for making any changes to DEP – until after hours.
In the meantime I got Joe McGlynn involved to see if he had ever seen such a thing when running dcdiag. He had not. He suggested taking options out one at a time and also running it on the local server only. This resulted in the same error.
EventID.net had a full page of Event ID 1000 errors but nothing that I could find that addressed this issue.
While I waited I started a Google search which provided thousands of non-helpful pages…
I then ran across a SINGLE post that was similar and this had the answer that I needed.
Even though the dll was not the same, the version of dcdiag he was discussing was the older version of dcdiag 5.2.3790.1830 which I had.
From Mark’s site “the service pack 2 version (3959) and dcdiag.exe is at service pack 1 (1830) – i.e. not at the same service pack revision.”
When I checked the version of dcdiag, sure enough it was 5.2.3790.1830 as was stated in the event log error.
I found the newer version of dcdiag on the DC. I changed the name of the original dcdiag and pasted the newer file into its place.
When I check the version property now I see 3959
I then re-ran dcdiag /c /a /v /f:C:\DCDIAG_AUG11.txt and it worked without issue.
Thanks goes out to James and Joe and to Mark Wilson for his excellent post!!
“Version mismatch was the first thing that came to my mind. Quite a common mistake, which I learnt the hard way.” Willem Kasdorp
I will know to look now. I have NEVER had dcdiag not work before. The NT5DS pop-up error got me on the wrong track with the time. BUT I will always check for the version now. Tim
I will know to look now. I have NEVER had dcdiag not work before. The NT5DS pop-up error got me on the wrong track with the time. BUT I will always check for the version now.
We had a fresh install of Server 2003 R2 SP2. This is on a IBM XSeries server which is running DC, DNS, GC only.
The Support Tools MSI was loaded from the R2 Disk located on BX2EVOL_EN R2 disk, which is dated 3/22/2006.
Doing so installed DCDIAG with the version # 5.2.3790.1830 which gave me the same errors as before.
The path is set to –
Path=C:\Program Files\Support Tools\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
The file msvcrt.dll is the correct version – due to SP2 – 5.2.3790.3959 and is located in the System32 folder.
Once I realized that the MSI on the R2 disk had the old file versions, I simply located the newest current version of the Support Tools and the CAB file. LINK
I then un-installed the old System Tools MSI and re-installed using the newer versions and CAB file.
Now all is well…
That’s what “I” get for assuming that the latest and greatest install disk would have the accompanying support tools, and for assuming that SP2 would update ALL of the files that would be affected…
I wonder if this is the case on other types of servers? These are all IBM servers… Where do you load your Support Tools from? From the install disk, or from the Microsoft web site.
“The support tools are an out-of-band release. While they’re usually updated at the same time as an SP the SP doesn’t update ’em. Also, R2 is built on SP1 and we’ve seen some funnies with deploying it and SP2 -doesn’t play. So you have to basically build as SP1, install R2 and then deploy SP2, i.e. slipstreamed SP2 and R2 don’t play. The same is obviously true of the support tools (makes sense). This is partly why MS dropped them (probably).
This won’t happen in NT6 as the way things are now components and we have file-system links to WinSxS mitigates this.
Good post though. Nice catch and thanks for sharing!” Paul Williams