trace of thought (Scott Colestock)

Retrieving "FullName" property for a local account...

Scott Colestock — Wed, 13 May 2009 14:24:59 GMT

You see quite a few code samples for retrieving "FullName" (or other properties) from an Active Directory that look like this:

string directoryPath = "WinNT://somedomain/someuser";

string fullName;



DirectoryEntry directoryEntry = new DirectoryEntry(directoryPath);

if (directoryEntry.Properties["FullName"].Value != null)

{

fullName = directoryEntry.Properties["FullName"].Value.ToString();

}

One issue with this code is that when "somedomain" actually corresponds to the local machine name (because your are trying to retrieve the "FullName" of a local account), it can take an extremely long time to run. This is probably because the underlying framework is off trying to find a domain controller before falling back to the local security store.

To work around this, consider code that would look like the following when formulating the directory path:

string[] identities = windowsIdentity.Name.Split('\\');

string directoryPath;

if(Environment.UserDomainName.Equals(Environment.MachineName,StringComparison.OrdinalIgnoreCase))

{

// special case needed for "off domain" case.

directoryPath = "WinNT://localhost/" + identities[1];

}

else

{

directoryPath = "WinNT://" + identities[0] + "/" + identities[1];

}

Using "localhost" will cause the property retrieval to be just about instantaneous, whereas using the computer name (from a local account Windows identity) results in up to a twelve second delay.

MIX09 Recap and Star Trek premier...

Scott Colestock — Fri, 17 Apr 2009 16:12:44 GMT

Star Trek Premier and MIX09 recap, all in one night in the Twin Cities on May 8th.
A match made in heaven, naturally.

Code Profiling talk (and utility)...

Scott Colestock — Sat, 04 Apr 2009 19:18:10 GMT

I had a chance to do a talk on profiling code for Microsoft's "Build Your Skills" event on March 24th in St. Louis (and March 31st in Minneapolis). I mentioned a utility I'd written for cleaning up performance session files that are generated from URLs (so that only DLL/EXE remain.) You can find that here. In addition, you can find the slides here. All sorts of fun details on profiling terminology, types of profiles, resigning assemblies (or turning off assembly verification), etc. I'm hoping to record a screen cast of the talk soon...

Fantastic turnout at both locations, and really great questions - thanks to those who attended!

TFS 2008 / Scrum talk at MN VSTS User Group...

Scott Colestock — Tue, 24 Mar 2009 19:42:42 GMT

I had a chance to do an updated version of my TFS 2008 / Scrum talk at the MN VSTS User Group. Slides are here.
What a great turnout! And great questions from the group...

Resolving WCF Fatal Execution Engine Error...

Scott Colestock — Tue, 24 Mar 2009 19:36:07 GMT

I haven't seen many "Fatal Execution Engine Error (79FFEE24)" sorts of messages lately - not since .NET 1.0/1.1 days.

But we were wrestling with an issue for multiple weeks in which a WCF service would crash with exactly this error. Since this service uses the DataContractSerializer, this post seemed quite relevant. The workarounds suggested there were not going to be a fit for us, unfortunately.

The really insidious part of this problem was that the initial failure mode was causing a third party library (that our service invoked) to fail...complete with a stack trace that pointed deep into the third party code. However, when we removed the call to this library, we got the "Fatal Execution Engine" exception while WCF was attempting to serialize the service response. (Really nasty, and it points to some sort of stack corruption perhaps.) You could see that WCF serialization was at fault by analyzing a crash dump of the IIS worker process with WinDbg.

After talking with some folks at Microsoft support, they indicated that the DataContractSerializer issue is fixed in .NET 4.0, but there is not a hotfix available for .NET 3.5sp1 at this time.

The workaround they proposed - and which has resolved our issue - was to place all assemblies that contain types "T" used in contracts that have IEnumerable<T> into the GAC. (In other words, if your contract has IEnumerable<T> elements, then all types T have to be strong-named & in the GAC.)

Why does this work? The bug with DataContractSerializer apparently does not manifest itself when assemblies are loaded as "domain neutral" (shared across all appdomains.) You can force strong-named/GAC'd assemblies to be loaded as "domain neutral" by using the LoaderOptimization attribute. But if you're hosting in IIS, you are automatically getting LoaderOptimization(LoaderOptimization.MultiDomainHost) behavior for your application. If you're not hosting in IIS, this bug doesn't seem to appear at all.

This workaround is a hassle, of course - it ripples across the application in many ways...but it does resolve the issue.