Friday, March 18, 2005

Deadlock in CLR involving GC & OS Loader lock.

When the Microsoft .NET Framework Execution Engine has to perform garbage collection (GC), the .NET Framework Execution Engine must first suspend all managed threads. In most circumstances, a managed thread must set itself so that it can be suspended before leaving its managed state to run unmanaged code. This thread state is named GC PreEmptable. The GC PreEmptable thread state must be entered by the managed thread before leaving the managed state.In this particular deadlock condition, three different threads are involved as follows:

•Thread 1: This thread is waiting for the Windows NT Loader Lock to complete its task.
•Thread 2: This thread is the owner of the Windows NT Loader Lock. This thread has been suspended by the garbage collection thread. This thread will not release the Windows NT Loader Lock until this thread is restarted by the .NET Framework Execution Engine after the garbage collection is completed. In this case, because the garbage collection is not going to complete, this thread will never release the NT Loader Lock.
•Thread 3: This is the garbage collection thread that is trying to complete garbage collection. To complete the garbage collection, the garbage collection thread has to suspend managed Thread 1 that is waiting for the Windows NT Loader Lock. Because Thread 1 cannot be suspended, the garbage collection is never completed.

This combination of thread conditions leads to a classic deadlock scenario that causes the application to stop responding.

For more information :

The KB article addresses the fix for a specific instance, but there is a generic problem when loading managed C++ dlls that such a condition can occur. This will be fixed only in the Whidbey timeframe. For details: Mixed Dll Loading Problem

The workaround for now (.NET 1.1) will be to preload the managed C++ dlls when a GC is not happening. There is currently no way to disable GC, but you can reduce the probability of GC by forcing a GC and pre-loading the dlls at startup.

Thursday, March 17, 2005

Eclipse for Java

Getting the right free plugins for Eclipse is important:

1. To develop J2EE programs, Tomcat web applications, browse and query database contents, edit Html, Xml, schema files etc. -
The 'Getting Started' site has installation information. Please note that this is still in beta but quite usable. This gives you pretty much everything for web development.

2. To develop Hibernate applications, edit mapping files & running queries. -
Here are the 'Download Instructions'.

3. The Spring IDE -
XmlSerializer in .NET

easier way to access xml than DOM.
maps xsd types to CLR types.
can only support datastructures that can be expressed in xsd.
can be executed in unsafe environments.
additionally support SOAP section-5 encoding
used by ASP.NET webservices.
generates and compiles code on the fly to do serialization and deserialization.
uses code dom compilation which requires use of temporary files on disk.
hence the process should have read/write permissions on the folder. use 'Filemon' to diagnose issues.
Enabling JIT debugging for managed code.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ .NETFramework\DbgJIT\ DebugLaunchSetting =2 (=1 to disable)
Debugging service/process startup.

Please refer to the excellent article:

Also, in Visual Studio set the 'Debugger' key to point to the VS solution as in
"devenv.exe my.sln /run"
Note that you can change the SCM timeout for the service startup in milliseconds at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control, ServicesPipeTimeout DWORD
Setting breakpoints in .NET webservice

Put the following in a .ini file which has the same name as the assembly & run iisreset.
[.NET Framework Debugging Control]
Debugging XMLSerializer usage in .NET webservice.

You can add a switch to the machine.config to keep compiler generated files:
[add name="XmlSerialization.Compilation" value="4"]
After this, the temp directory would have the generated files.
Running out of user ports under stress

This is generally useful if you are creating and closing a lot of connections:
\HKLM\System\CurrentControlSet\Services\Tcpip\Parameters MaxUserPort REG_DWORD 0xfffe
\HKLM\System\CurrentControlSet\Services\Tcpip\Parameters TcpTimedWaitDelay REG_DWORD 0x2
Checking if client and server are the same machine.

bool IsClientAndServerSame(HttpRequest request)
String remoteAddress = request.UserHostAddress;
if (remoteAddress == null remoteAddress.Length == 0)
return false;
if (remoteAddress == "" remoteAddress == "::1")
return true;
if (remoteAddress == request.LocalAddress)
return true;
return false;
Dynamically loading .NET assemblies.

It is not possible to unload a single assembly, so usually you have to load such assemblies in a separate appdomain to ensure proper cleanup. has additional information on how to load an assembly in another appdomain.
Debugging .NET assembly load failures

Run fuslogvw.exe, set [HKLM\Software\Microsoft\Fusion\ForceLog] DWORD value to 1. For ASP.NET, select the “Custom” option, and in regedit, set [HKLM\Software\Microsoft\Fusion\LogPath] to some directory other than root.
Interlocked exchange operation on 64bit.

CMPXCHG8B instruction with the lock prefix can be used on x86, but you should first verify the presence of the instruction using IsProcessorFeaturePresent(PF_COMPARE_EXCHANGE_DOUBLE)
Memory Barriers

Memory barrier ensures that all reads/writes before the barrier have completed on the local processor thus separating accesses following the barrier from those before it.

.NET Memory barrier is a no-op in x86, but is required in ia64, RISC platforms etc.