DsGetDcName Timeout

Today I was looking for the source of frequent delays when setting permissions from my new application SetACL Studio. I sprinkled the code with timestamped debug statements like these…

System.Diagnostics.Debug.WriteLine(DateTime.Now + " - 1");
// Do something
System.Diagnostics.Debug.WriteLine(DateTime.Now + " - 2");

…and found that the delays always had a duration of seven seconds. Wait - “inexplicable” delays of constant length - that smells of timeouts!

And indeed, by stepping into the underlying unmanaged code it was pretty easy to identify the call causing the timeouts:

if (DsGetDcName (NULL, sDomainName, NULL, NULL, 0, &pdcInfo) == ERROR_SUCCESS)

This happened if sDomainName was equal to the local computer name, i.e. when looking for a (nonexistent) domain with the name of my computer.

I fixed that line by adding a check if sDomainName is different from the local computer name:

CString sComputername;
sComputername.GetEnvironmentVariable(L"computername");
if (sComputername.CompareNoCase(sDomainName) != 0)
{
   // Call DsGetDcName here
}

Comments

Related Posts

How to Enable Drag and Drop for an Elevated MFC Application on Windows

Finding good information on how to enable drag and drop for MFC applications is hard enough (why?). But just when you think you should have it working, you hit a very solid wall: UIPI (User Interface Privilege Isolation, a variant of UAC, User Account Control). Because of “security” reasons, UIPI disables drag and drop from medium integrity processes (Explorer) to high integrity (aka elevated) processes by filtering out most window messages, including those required for drag and drop. In essence drag and drop from Explorer to your elevated application does not work.
Software development

Visual Studio: Fixing Broken $(WindowsSdkDir) Variable

If you get weird errors in Visual Studio that basically state files like Windows.h cannot be found, the reason may be a missing or incorrect WindowsSdkDir variable. In my case, working with Visual Studio 2008 SP1 (32 bit) on Windows 7 x64 (64 bit) everything was fine until I installed the Windows 7 SDK. After that, no SDK files could be found any more and nothing would compile. Uninstalling the SDK (which I did not really need anyway - I had installed it only to get at XPerf) did not help. After some research, I found out that the Visual Studio internal variable WindowsSdkDir (which is not an environment variable) was missing from the registry. After adding the following, everything worked like a charm again:
Software development

Latest Posts

Filebrowser to Be Archived. Migrate to a Modern Alternative: Sambee

Filebrowser to Be Archived. Migrate to a Modern Alternative: Sambee
Filebrowser is being archived. As the author writes, the codebase dates back to when he was but 15 years old. Having created such a popular file management tool is a more than impressive achievement for anyone, let alone a teenager. However, when it comes to security and reliability, Filebrowser seems to be built on a less than ideal foundation, so much so that the author states:
Home Automation, Networking & Self-Hosting