memory.Refresh()

I was working on some code that seemed to take an age to get going. Simple I thought: run it throught the Red Gate ANTS Profiler, look at the offending code and sort the problem. I wish it was as straightforward. Profiling or debugging the code seemed to make it run quickly, so I had to resort to the good old technique of logging debug output line by line.

After finding the lethargic code, the line that stalled progress for almost a minute didn’t look that concerning:

Process.GetCurrentProcess().ProcessName

A bit of Googling turned up trumps. A post by Brian Grunkemeyer from the BCL team gave the answer:

The way the Process class currently works, the first time you try to do anything that requires knowing the state of the current process, we take a snapshot of all the processes in the system. So yes, this operation is slow the first time you call it. We could potentially limit this snapshot to just the current process by requesting MORE information about the current process from Windows (CreateToolhelp32Snapshot is a peculiar method), but that leads into peculiar situations where the snapshot information for the current process then gets out of sync if you call another method on the Process class to enumerate all the other processes.

This initial snapshot must have been the cause of the delay. A quick code-edit later to avoid the use of the Process class (I was actually interested in the name of the executing file so I used Assembly.GetExecutingAssembly()) and the almost 60 second pause was gone.

So why was it running quicker when debugging/profiling? I presume that the debugger/profiler would have been using the System.Diagnostics namespace, and more specifically the Process class, as part of its internals, thus the costly first call snapshot had already happened.

After having several problems with my laptop accessing files on my server (the domain controller for my domain), I had a look in the event log and found this error:

The computer [computername] tried to connect to the server \\[servername] using the trust relationship established by the [domainname] domain. However, the computer lost the correct security identifier (SID) when the domain was reconfigured. Reestablish the trust relationship.

I figured that this may be the cause of the problems and so set about reestablishing the trust relationship between the laptop and the server. Sounded like a simple task, but the only (easy) way I could find to do this was to remove the laptop from the domain and then add it again. After removing it successfully, I kept getting an error when trying to re-add it:

The domain name [domainname] might be a NetBIOS domain name. If this is the case, verify that the domain name is properly registered with WINS.
If you are certain that the name is not a NetBIOS domain name, then the following information can help you troubleshoot your DNS configuration.
An error occurred when DNS was queried for the service location (SRV) resource record used to locate a domain controller for domain [domainname].
The error was: "No DNS servers configured for local system." (error code 0×0000267C DNS_ERROR_NO_DNS_SERVERS)
The query was for the SRV record for _ldap._tcp.dc._msdcs.[domain]”

After puzzling for ages as to why it wasn’t happy, I checked my IP settings and found the problem. Somehow, the IP settings had changed to a specified IP address instead of using DHCP. Changing them back solved the problem straight away.

I don’t really play games on my PC, but this Cats game from Ferry Halim’s site has me addicted. I think it must be because of the pure simplicity of the game, but I suspect it also has something to do with the hypnotic accompanying music. De doo de doo duh, de doo duh. Doo duh, doo de doo duh…

Jamie Cansdale from TestDriven.Net posted about certain security software breaking remoting with .Net 2.0. He also includes a downloadable example to demonstrate the problem.

The current list of culprits is:

• NOD32
• Trend Micro Office Scan
• Embassy Trust Suite
• Broadcom Advanced Control Suite
• NetLimiter

The common thread amongst these is that they all have some network monitoring functionality.

The error occurs whenever a .Net TCP remoting channel is closed. Perculiarly, the error happens not on the end that closes the channel, but in the application on the other end of the channel.

The stack trace of the error is:

Exception: System.AccessViolationException
Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Server stack trace:  
at System.Net.UnsafeNclNativeMethods.OSSOCK.WSAGetOverlappedResult(SafeCloseSocket socketHandle, IntPtr overlapped, UInt32& bytesTransferred, Boolean wait, IntPtr ignored)  
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)  
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)  

I tried the sample code as described with NOD32, remoting to both localhost and to a separate PC but could not get the behaviour.

Update: Jon Cole from Microsoft has posted on the MSDN forums verifying that this is indeed a bug, and that it should be fixed in the next release.

Chris Sells posted a useful tip (courtesy of Scott Guthrie) about duplicate types when compiling using the web application project model in Visual Studio 2005.

The error displays as:

Compilation Error

Description: An error occurred during the compilation of a resource required to service this request.
 
Please review the following specific error details and modify your source code appropriately.
 
Compiler Error Message: CS0433: The type 'ASP.clientredirector_ascx' exists in both 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\sb2\4d76034e\bec2c8d0\App_Web_clientredirector.ascx.cdcab7d2.zmdrab5k.dll' and 'C:\Windows\Microsoft.NET\v2.0.50727\Temporary ASP.NET Files\sb2\4d76034e\bec2c8d0\App_Web_axhgbqrn.dll'

The solution is simply (although not obviously) to add the batch="false" attribute to the compilation element in the web.config file:

<configuration ...>
    <system.web>
        <compilation batch="false"/>

This generates a lot fewer assemblies and avoids the problem.

Update: According to Mike Harder (a Software Design Engineer on the ASP.NET team) in his recent post on the ASP.Net forums, this is a known bug in the ASP.Net compiler involving directory level circular references. An alternative fix to the batch="false" option is to reorganise the files in the web application to avoid a circular reference.