Internet Explorer에 Embedding된 UserControl안에서 Syetem.Net.Sockets.TcpClient를 사용하는 경우, .NET Framework 2.0 SP1이후 Version에서 Hang 현상이 발생할 수 있다. 
 

이는 Internet Explorer환경이 Proxy Server를 이용하여 URL redirect가 되는 경우, redirect되는 URL에 %20 등과 같은 International Characters가 포함되었다면, 이것이 원인이 될 수 있으며 해당 어셈블리가 초기화되는 시점에 다음과 같은 코드를 추가함으로써 이 문제를 피해갈 수 있다.

public UserControl1()

{

            Type uriType = typeof(Uri);

            FieldInfo UriConfigInitField;

            UriConfigInitField = uriType.GetField("s_ConfigInitialized",

                BindingFlags.Static | BindingFlags.NonPublic);

            UriConfigInitField.SetValue(uriType, true);

            FieldInfo IriParsingField = uriType.GetField("s_IriParsing",

                BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField);

            IriParsingField.SetValue(uriType, false);

            FieldInfo IdnScopeField = uriType.GetField("s_IdnScope",

                BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField);

            IdnScopeField.SetValue(uriType, UriIdnScope.None);

//. . .

}

private void button1_Click(object sender, EventArgs e)
{
    string hostname = "...";
    int port = 0xbb7;

    TcpClient client = new TcpClient(hostname, port);
. . .
}
 

이는 다음의 Callstack과 Redirect URL에 International 문자열이 존재하는 지를 가지고 verification할 수 있다.

0:003> !clrstack
OS Thread Id: 0xc70 (3)
ESP       EIP    
01dcec94 7c90e514 [GCFrame: 01dcec94]
01dced68 7c90e514 [HelperMethodFrame_1OBJ: 01dced68] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)
01dcedcc 792cbd18 System.Threading.Monitor.Wait(System.Object, Int32, Boolean)
01dceddc 028d00d8 System.Configuration.ClientConfigurationSystem.EnsureInit(System.String)  <<<<<
01dcee18 0751ffcc System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(System.String)
01dcee24 0751ff64 System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(System.String)
01dcee38 0751db70 System.Configuration.ConfigurationManager.GetSection(System.String)
01dcee44 0751db21 System.Configuration.PrivilegedConfigurationManager.GetSection(System.String)
01dcee54 03366add System.Configuration.UriSectionInternal.GetSection()
01dcee88 03366837 System.Uri.GetConfig(System.UriIdnScope ByRef, Boolean ByRef)
01dceed4 0336671d System.Uri.InitializeUriConfig()
01dcef00 05fd160a System.Uri.InitializeUri(ParsingError, System.UriKind, System.UriFormatException ByRef)
01dcef34 0336663a System.Uri.CreateThis(System.String, Boolean, System.UriKind)
01dcef54 03366511 System.Uri.CreateUri(System.Uri, System.String, Boolean)
01dcef70 0336647b System.Uri..ctor(System.Uri, System.String)
01dcef84 03365e3a System.Net.HttpWebRequest.CheckResubmit(System.Exception ByRef)
01dcefc8 033631c8 System.Net.HttpWebRequest.DoSubmitRequestProcessing(System.Exception ByRef)
01dceffc 03362fcb System.Net.HttpWebRequest.ProcessResponse()
01dcf034 03361a08 System.Net.HttpWebRequest.SetResponse(System.Net.CoreResponseData)
01dcf070 033618c4 System.Net.HttpWebRequest.CheckWriteSideResponseProcessing()
01dcf080 02babb1a System.Net.HttpWebRequest.EndSubmitRequest()
01dcf0b8 02bab65c System.Net.HttpWebRequest.SetRequestSubmitDone(System.Net.ConnectStream)
01dcf0c8 02bab359 System.Net.Connection.CompleteConnection(Boolean, System.Net.HttpWebRequest)
01dcf118 02ba8486 System.Net.Connection.CompleteStartConnection(Boolean, System.Net.HttpWebRequest)
01dcf164 02ba8206 System.Net.Connection.CompleteStartRequest(Boolean, System.Net.HttpWebRequest, System.Net.TriState)
01dcf194 02ba7b10 System.Net.Connection.SubmitRequest(System.Net.HttpWebRequest)
01dcf1dc 02ba5fb7 System.Net.ServicePoint.SubmitRequest(System.Net.HttpWebRequest, System.String)
01dcf214 02b8f055 System.Net.HttpWebRequest.SubmitRequest(System.Net.ServicePoint)
01dcf240 02b89de0 System.Net.HttpWebRequest.GetResponse()
01dcf280 02b8d333 System.Net.AutoWebProxyScriptEngine.DownloadAndCompile(System.Uri, System.Net.AutoWebProxyScriptWrapper ByRef, Int32 ByRef)
01dcf2f0 02b8c971 System.Net.AutoWebProxyScriptEngine.EnsureEngineAvailable(Int32 ByRef)
01dcf308 02b8baed System.Net.AutoWebProxyScriptEngine.GetProxies(System.Uri, Boolean, System.Net.AutoWebProxyState ByRef, Int32 ByRef)
01dcf350 02b8b9a5 System.Net.WebProxy.GetProxiesAuto(System.Uri, System.Net.AutoWebProxyState ByRef, Int32 ByRef)
01dcf36c 02b8b8ee System.Net.ProxyScriptChain.GetNextProxy(System.Uri ByRef)
01dcf380 02b8b7f0 System.Net.ProxyChain+ProxyEnumerator.MoveNext()
01dcf3b4 02b8aa36 System.Net.ServicePointManager.FindServicePoint(System.Uri, System.Net.IWebProxy, System.Net.ProxyChain ByRef, System.Net.HttpAbortDelegate ByRef, Int32 ByRef)
01dcf3f4 02b8a90e System.Net.HttpWebRequest.FindServicePoint(Boolean)
01dcf424 02b89dd6 System.Net.HttpWebRequest.GetResponse()
01dcf464 02b89b70 System.Net.WebClient.GetWebResponse(System.Net.WebRequest)
01dcf470 02b89b16 System.Net.WebClient.DownloadBits(System.Net.WebRequest, System.IO.Stream, System.Net.CompletionDelegate, System.ComponentModel.AsyncOperation)
01dcf494 02b86f17 System.Net.WebClient.DownloadDataInternal(System.Uri, System.Net.WebRequest ByRef)
01dcf4c4 02b86d5f System.Net.WebClient.DownloadData(System.Uri)
01dcf4f8 02b846c2 System.Net.WebClient.DownloadData(System.String)
01dcf504 028d2231 System.Configuration.ClientConfigurationHost.OpenStreamForRead(System.String)
01dcf538 028d0e29 System.Configuration.BaseConfigurationRecord.InitConfigFromFile()
01dcf620 0751f162 System.Configuration.BaseConfigurationRecord.Init(System.Configuration.Internal.IInternalConfigRoot, System.Configuration.BaseConfigurationRecord, System.String, System.String)
01dcf87c 0751e105 System.Configuration.RuntimeConfigurationRecord.Create(System.Configuration.Internal.InternalConfigRoot, System.Configuration.Internal.IInternalConfigRecord, System.String)
01dcf890 028d051e System.Configuration.Internal.InternalConfigRoot.GetConfigRecord(System.String)
01dcf8e4 028d019f System.Configuration.ClientConfigurationSystem.EnsureInit(System.String)   <<<<<
01dcf920 0751ffcc System.Configuration.ClientConfigurationSystem.PrepareClientConfigSystem(System.String)
01dcf92c 0751ff64 System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(System.String)
01dcf940 0751db70 System.Configuration.ConfigurationManager.GetSection(System.String)
01dcf94c 0751db21 System.Configuration.PrivilegedConfigurationManager.GetSection(System.String)
01dcf95c 0751dacd System.Diagnostics.DiagnosticsConfiguration.GetConfigSection()
01dcf964 0751d8f9 System.Diagnostics.DiagnosticsConfiguration.Initialize()
01dcf990 0751d812 System.Diagnostics.DiagnosticsConfiguration.get_Sources()
01dcf99c 0751d658 System.Diagnostics.TraceSource.Initialize()
01dcf9cc 0751d2f8 System.Net.Logging.InitializeLogging()
01dcf9fc 0751d1bf System.Net.Logging.get_On()
01dcfa00 0751d01c System.Net.Sockets.TcpClient..ctor(System.String, Int32)
01dcfa30 0751ba1f Simple.UserControl1.button1_Click(System.Object, System.EventArgs)
01dcfaa4 0751a3a7 System.Windows.Forms.Control.OnClick(System.EventArgs)
01dcfab8 0751b992 System.Windows.Forms.Button.OnClick(System.EventArgs)
01dcfac8 0751b87c System.Windows.Forms.Button.OnMouseUp(System.Windows.Forms.MouseEventArgs)
01dcfae4 0751a235 System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
01dcfb74 05fdae1f System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
01dcfb78 0613a84d [InlinedCallFrame: 01dcfb78]
01dcfc08 0613a6c3 System.Windows.Forms.Button.WndProc(System.Windows.Forms.Message ByRef)
01dcfc14 05fda8c0 System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)
01dcfc1c 05fda898 System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)
01dcfc30 05fda6e8 System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)
01dcfd4c 03732714 [ContextTransitionFrame: 01dcfd4c]

.." Use the static modifier to declare a static member, which belongs to the type itself rather than to a specific object. The static modifier can be used with classes, fields, methods, properties, operators, events and constructors, but cannot be used with indexers, destructors, or types other than classes. " ... http://msdn.microsoft.com/en-us/library/98f28cdx(VS.80).aspx

하지만, static keyword가 Thread Safe와는 친하지 않기 때문에 Multiple users 나 Threads 환경에서 race condition에 따라 Data가 Corruption되거나 NullReferenceException이 발생할 수도 있다.

0:031> kb

ChildEBP RetAddr  Args to Child             

0d4ff0d4 7923b543 e0434f4d 00000001 00000000 kernel32!RaiseException+0x53

0d4ff12c 7923b4c6 069703b0 00000000 0d4ff388 mscorsvr!RaiseTheException+0xa0

0d4ff154 7923b47a 069703b0 00000000 0d4ff398 mscorsvr!RealCOMPlusThrow+0x48

0d4ff164 79239c8c 069703b0 0000002b 00000000 mscorsvr!RealCOMPlusThrow+0xd

0d4ff398 792b718e 0000002b 00000000 00000000 mscorsvr!CreateMethodExceptionObject+0x67b

0d4ff42c 792b71b2 80004003 00000000 00000000 mscorsvr!RealCOMPlusThrowHRWorker+0xb9

0d4ff448 792b731c 80004003 00000000 00000000 mscorsvr!RealCOMPlusThrowHRWorker+0x15

0d4ff4d4 792a8552 80004003 00000000 0d4ff514 mscorsvr!RealCOMPlusThrowHR+0x168

0d4ff4e8 0268435d 00000000 00000000 80004003 mscorsvr!Interop::ThrowExceptionForHR+0x3a

WARNING: Frame IP not in any known module. Following frames may be wrong.

0d4ff660 791f6049 00000001 0d4ff69c 791f609d 0x268435d

0d4ff66c 791f609d 0cafa2d8 0695800c 00000000 mscorsvr!CTPMethodTableCallTargetHelper+0xf

0d4ff69c 791fa7f8 0cafa2d8 0695800c 00000000 mscorsvr!CTPMethodTable::CallTarget+0x4e

0d4ff6c0 791b2682 0cb06e5c 00000000 00000001 mscorsvr!CRemotingServices::CreateProxyOrObject+0x5f

0d4ff730 791b273c 0cb06e5c 0caff013 00000000 mscorsvr!AppDomain::GetOffsetOfSlotsCount+0xa0

0d4ff74c 791b7f92 0d4ff864 791bdd4e 0d4ff7a0 mscorsvr!JIT_NewCrossContext+0x3a

0d4ff754 791bdd4e 0d4ff7a0 00000000 0d4ff778 mscorsvr!CallDescrWorker+0x30

0d4ff864 791d5bd5 00b07f53 026e8a10 024547a0 mscorsvr!MethodDesc::CallDescr+0x1b8

0d4ff88c 79236659 0d4ff8a8 024547a0 0d4ffc8c mscorsvr!MethodDesc::Call+0x8e

0d4ff8b8 792cec0a 069700c8 0d4ff934 02683c9a mscorsvr!CallDefaultConstructor+0x10c

0d4ff8c4 02683c9a 0d4ff8d0 069700c8 0cafec57 mscorsvr!CRemotingServices::CallDefaultCtor+0xd

0:031> !do 069703b0

Name: System.NullReferenceException

0:031> !dumpstack -EE

Thread 31

Current frame:

  ChildEBP RetAddr    Caller,Callee

0d4ff51c 0cafd1f5 (MethodDesc 0xcb03410 +0x255 System.EnterpriseServices.Thunk.Proxy.CoCreateObject)

0d4ff548 0cafd107 (MethodDesc 0xcb03410 +0x167 System.EnterpriseServices.Thunk.Proxy.CoCreateObject)

0d4ff600 0cafc0e4 (MethodDesc 0x2643ea0 +0x64 System.Runtime.Remoting.RemotingConfigHandler.IsRemotelyActivatedClientType)

0d4ff608 0cafc6df (MethodDesc 0xcb037d0 +0x1f System.EnterpriseServices.ServicedComponentInfo.SCICachedLookup)

0d4ff610 0cafa8a3 (MethodDesc 0xcb015c8 +0xb3 System.EnterpriseServices.ServicedComponentProxyAttribute.CreateInstance)

0d4ff654 0cafa320 (MethodDesc 0x24fe618 +0x48 System.Runtime.Remoting.Activation.ActivationServices.IsCurrentContextOK)

0d4ff6f0 0caff8f6 (MethodDesc 0xcb07600 +0x6e System.EnterpriseServices.RWHashTableEx.Put)

0d4ff738 0caff013 (MethodDesc 0xcb01710 +0x2b ttt.obj.objMTS..ctor)

0d4ff748 0d50071e (MethodDesc 0xcb07f58 +0x6 ttt.objMain.obj_11..ctor)

0d4ff8d0 0cafec57 (MethodDesc 0x21c9240 +0x7f System.Runtime.Remoting.Proxies.RealProxy.InitializeServerObject)

0d4ff8f4 0cafec95 (MethodDesc 0x21c9240 +0xbd System.Runtime.Remoting.Proxies.RealProxy.InitializeServerObject)

0d4ff920 0cafe77d (MethodDesc 0xcb02e88 +0x85 System.EnterpriseServices.ServicedComponentProxy.SetupContext)

0d4ff934 0cafe683 (MethodDesc 0xcb02d28 +0x1b System.EnterpriseServices.ServicedComponentProxy.ConstructServer)

0d4ff940 0cafe441 (MethodDesc 0xcb02bc8 +0x141 System.EnterpriseServices.ServicedComponentProxy..ctor)

0d4ff96c 0cafe0f2 (MethodDesc 0xcb015f8 +0x8a System.EnterpriseServices.ServicedComponentProxyAttribute.System.Runtime.InteropServices.ICustomFactory.CreateInstance)

0d4ff994 0cafdda3 (MethodDesc 0x24fe628 +0x4b System.Runtime.Remoting.Activation.ActivationServices.CreateObjectForCom)

0d4ffc74 0cafdd24 (MethodDesc 0xcb034a0 +0x6c System.EnterpriseServices.Thunk.Proxy.CallFunction)

0d4ffc98 0cafdd24 (MethodDesc 0xcb034a0 +0x6c System.EnterpriseServices.Thunk.Proxy.CallFunction)

0d4ffcc0 0cafdc87 (MethodDesc 0xcb05a28 +0x67 System.EnterpriseServices.Internal.AppDomainHelper.System.EnterpriseServices.Internal.IAppDomainHelper.DoCallback)

상위 Callstack은 NullReferenceException이 발생한 것을 보여주는 데, ttt.obj.objMTS..ctor Constructor에서의 NulLReferenceException이므로, ttt.obj.objMTS 라는 Class의 초기화에서 NullReferenceException이 발생한 것을 알 수 있다. 하지만, 해당 Dump에서는 몇몇의 Thread가 상위의 NullReferenceException이 발생한 Class의 Constructor와 관련이 있다는 것이다. 아래의 callstack은 상위의 NullReferenceException이 발생한 Constructor의 진행과정을 보여주고 있다. 이게 무엇을 의미하는 가.

0:030> kb

ChildEBP RetAddr  Args to Child             

0d48f0bc 7943b437 024327c0 02430010 02431e5c mscorjit!Compiler::fgSetStmtSeq+0x38

0d48f0d0 7943b466 02431e5c 0d48f328 02430010 mscorjit!Compiler::fgSetBlockOrder+0x17

0d48f0e0 794311b5 00000000 02430010 0d48f13c mscorjit!Compiler::fgSetBlockOrder+0x26

0d48f0f0 79431581 0d48f204 0d48f380 0d48f1f8 mscorjit!Compiler::compCompile+0xa4

0d48f13c 79431622 00130628 0d48f2dc 0d48f328 mscorjit!Compiler::compCompile+0x1e8

0d48f1c4 794316ac 0d48f2dc 0d48f328 0d48f204 mscorjit!jitNativeCode+0x95

0d48f208 791bfd04 79479124 0d48f2dc 0d48f328 mscorjit!CILJit::compileMethod+0xa2

0d48f250 791b91f4 000e38a0 0d48f2dc 0d48f328 mscorsvr!CallCompileMethodWithSEHWrapper+0x52

0d48f3b8 791b95bf 0cb0bab0 0d48f580 0d48f4bc mscorsvr!JITFunction+0x2c7

0d48f4ec 791b4428 0cb0bab0 0d48f580 00000000 mscorsvr!MakeJitWorker+0x2c0

0d48f5d8 791b453f 00000000 0d48f8ec 0d48f614 mscorsvr!MethodDesc::DoPrestub+0x4d3

0d48f5f0 02102f76 0d48f614 00000000 029203b0 mscorsvr!PreStubWorker+0x42

WARNING: Frame IP not in any known module. Following frames may be wrong.

00000000 00000000 00000000 00000000 00000000 0x2102f76

0:030> !dumpstack -EE

Thread 30

Current frame:

  ChildEBP RetAddr    Caller,Callee

0d48f61c 0d509747 (MethodDesc 0xcb0baa0 +0x17 System.Xml.XPath.XPathParser.ParseAdditiveExpr)

0d48f634 0d50968f (MethodDesc 0xcb0ba90 +0x17 System.Xml.XPath.XPathParser.ParseRelationalExpr)

0d48f64c 0d509537 (MethodDesc 0xcb0ba80 +0x17 System.Xml.XPath.XPathParser.ParseEqualityExpr)

0d48f664 0d509332 (MethodDesc 0xcb0ba70 +0x12 System.Xml.XPath.XPathParser.ParseAndExpr)

0d48f678 0d5092ba (MethodDesc 0xcb0ba60 +0x12 System.Xml.XPath.XPathParser.ParseOrExpr)

0d48f68c 0d5086d0 (MethodDesc 0xcb0ba30 +0x38 System.Xml.XPath.XPathParser.ParseXPathExpresion)

0d48f698 0d507738 (MethodDesc 0xcb0a3d8 +0x38 System.Xml.XPath.XPathNavigator.Compile)

0d48f6b0 0d5076df (MethodDesc 0xcb0a458 +0x1f System.Xml.XPath.XPathNavigator.Select)

0d48f6c0 0d506e6c (MethodDesc 0xc8609e8 +0x24 System.Xml.XmlNode.SelectSingleNode)

0d48f6e4 0d500391 (MethodDesc 0xcb06a98 +0x79 aaa.ClassMain.Config.xmlLoad)

0d48f728 0caff1d1 (MethodDesc 0xcb06a38 +0x79 aaa.ClassMain.Config..ctor)

0d48f730 0caff0d0 (MethodDesc 0xcb06a58 +0x28 aaa.ClassMain.Config.GetConfig)

0d48f738 0cafeff9 (MethodDesc 0xcb01710 +0x11 ttt.obj.objMTS..ctor)

0d48f748 0caff08e (MethodDesc 0xcb01820 +0x6 ttt.objMain.obj_Comp..ctor)

0d48f8d0 0cafec57 (MethodDesc 0x21c9240 +0x7f System.Runtime.Remoting.Proxies.RealProxy.InitializeServerObject)

0d48f8f4 0cafec95 (MethodDesc 0x21c9240 +0xbd System.Runtime.Remoting.Proxies.RealProxy.InitializeServerObject)

0d48f920 0cafe77d (MethodDesc 0xcb02e88 +0x85 System.EnterpriseServices.ServicedComponentProxy.SetupContext)

0d48f934 0cafe683 (MethodDesc 0xcb02d28 +0x1b System.EnterpriseServices.ServicedComponentProxy.ConstructServer)

0d48f940 0cafe441 (MethodDesc 0xcb02bc8 +0x141 System.EnterpriseServices.ServicedComponentProxy..ctor)

0d48f96c 0cafe0f2 (MethodDesc 0xcb015f8 +0x8a System.EnterpriseServices.ServicedComponentProxyAttribute.System.Runtime.InteropServices.ICustomFactory.CreateInstance)

0d48f994 0cafdda3 (MethodDesc 0x24fe628 +0x4b System.Runtime.Remoting.Activation.ActivationServices.CreateObjectForCom)

0d48fc74 0cafdd24 (MethodDesc 0xcb034a0 +0x6c System.EnterpriseServices.Thunk.Proxy.CallFunction)

0d48fc98 0cafdd24 (MethodDesc 0xcb034a0 +0x6c System.EnterpriseServices.Thunk.Proxy.CallFunction)

0d48fcc0 0cafdc87 (MethodDesc 0xcb05a28 +0x67 System.EnterpriseServices.Internal.AppDomainHelper.System.EnterpriseServices.Internal.IAppDomainHelper.DoCallback)

Callstack만 봐서는 문제가 없어 보일 수 있다. 단지, ttt.obj.objMTS..ctor 가 호출되는 2개의 Threads를 본 것이기 때문이다. 하지만, 여기서 ttt.obj.objMTS class의 Constructor안에서 호출되는 aaa.ClassMain.Config.GetConfig function을 들여다 보면, 다음과 같다.

.method public hidebysig static class aaa.ClassMain.Config.GetConfig

        GetConfig() cil managed

{

  // Code size       23 (0x17)

  .maxstack  1

  IL_0000:  ldsfld     class aaa.ClassMain.Config aaa.ClassMain.Config::self

  IL_0005:  brtrue.s   IL_0011

  IL_0007:  newobj     instance void aaa.ClassMain.Config::.ctor()

  IL_000c:  stsfld     class aaa.ClassMain.Config aaa.ClassMain.Config::self

  IL_0011:  ldsfld     class aaa.ClassMain.Config aaa.ClassMain.Config::self

  IL_0016:  ret

} // end of method Config::GetConfig

.field private static class aaa.ClassMain.Config self

즉, aaa.ClassMain.Config.GetConfig 는 static function이며, 그 보다, 그 안에서 Initialize 되는 aaa.ClassMain.Config Class는 self 라는 static variable 로 assign 이 된다. 물론, 예상대로 aaa.ClassMain.Config 는 Config File의 XML data를 load 하여 parsing 및 저장하여 가지고 있는 개체이다. 하지만, 이러한 data 들은 결코 Thread-safe 하지 않는 상태로 Multiple Threads에 의해서 접근이 가능하다는 것이며, 이러한 data의 초기화 시점에 race condition이 발생한다는 데 있다. 상위의 Callstack (System.EnterpriseServices.Thunk.Proxy.CoCreateObject )을 보면, 예상할 수 있겠지만, 이는 COM+ 혹은 Enterprise Services Application Call이며, Object Pooling과 같은 구조의 Component 초기화는 그러한 위험성을 내포하고 있다.

이와 같은 상황에 대해서 문서 http://support.microsoft.com/kb/893666/en-us " Troubleshooting ASP.NET applications with the use of static keywords" 에서는 여러 가지 우려한 시나리오를 언급하고 있다. 이것도 그 중 하나일 것이다. 

상위의 문제를 해결하기 위해서는 우선적으로 Thread-Safe 하게 접근하는 것이 우선적일 것이다. Static Keyword 를 사용하지 않는 것도 필요하다면 고려할 수 있지만, Data의 Locking이나 Synchronization 을 고려한 코드의 일부 수정으로써 문제를 풀어나가는 것도 고려해 볼 수 있지 않나 본다.

모처럼 회사 동료의 결혼식에서 주례사의 말씀을 찬찬히 들어볼 기회가 있었는데, 시작이 돌아가신 전대통령의 일기에 언급된 인생은 아름다고, 역사는 …  이었다. 이어서 이어지는 돌아가신 박경리선생님의 말씀도.. 역시 같은 맥락인 인생은 너무나도 아름답다는 것이다. 결혼을 통해서 새롭게 시작하는 이들에게는 필요한 말이 아닐까 한다. 물론, 잊지 않고 고달픔이 있을 것이라는 것, 이것을 직시하고 슬기롭게 이겨내는 것도 필요함을 잊지 않으셨다. 사실 기억해보면, 나 같이 아무 생각 없이 결혼식에 참가하여 다소 지루함을 못 견뎌 주례사의 말씀을 식사 나오기 전까지의 killing time 용으로 경청하는 사람 및 몇몇을 제외하고는 당사자인 분들을 포함해 정신 없이 바쁜 이들에게는 이러한 좋은 어구가 들렸을 까. 여태 수 십 차례 결혼식을 참가했지만, 이렇게 맘에 와 닫는 주례사는 처음이었다. 항상 형식적인 결혼식의 참가와 형식적인 축하 그리고, 한끼를 때우는 욕심 등이 지금까지 나의 태도에 있어서 부끄럽게 만들었다. 죽음 자체는 아무런 의미가 없고.. 인생이 너무나 아름답다. (아.. Old and Wise,) 이 말을 이해하기엔 난 아직 어린것 같다.

사실 우리가 살아가는 동안 행복하다고 느낄 때에는 사소한 것들조차 기쁨으로 다가오며, 이때에는 누가 뭐라 해도 인생은 아름답다고 느끼지 않을 까. 하지만, 조금이라도 불행하다면, 과연 인생은 아름답다라고 느낄 수 있을 까. 최근에 읽은 러셀의 “행복의 정복”을 보면, 우리가 왜 불행한가에 대한 언급이 있다. 병이나 배고픔과 같은 기본적인 육체적인 고통을 제외하고라도 정신적으로 만족스럽지 못해서 발생하는 불행의 원인인 즉, 경쟁, 권태, 자극, 피로, 질투, 피해망상, 죄의식 및 대중에 대한 두려움에 대해서는 하나씩 직시하고 언급하였다. 특히 알랭드 보통의 “불안”에서도 언급된 peer간의 경쟁과 질투는 결코 알면서도 올바로 의식하지 못했던 부분이다. 사실 범접할 수 없던 태생적으로 다른 이와의 비교에서는 질투보다는 체념이 따르기 때문에 포기되는 부분으로 스스로를 괴롭히진 않는 다. 하지만, 지금 같은 만민 평등 시대에서 똑같은 조건에서 태어나고 자랐다고 여기는 주변의 누구는 소위 부동산에, 주식에 일가견이 있어서 지금 시대의 성공의 척도가 되는 재화의 축적을 보란 듯이 했다는 소식만 들어도 그에 따른 질투와 열등감 그리고, 경쟁의식에 피곤하고 불행해진다. 그와 반대로 부에 대해서 끊임없이 추구하여 이들의 부러움을 사는 이들조차 지속적인 부의 축적 및 이에 대한 유지를 위한 쉬지 않는 경쟁 및 피로, 그리고, 경쟁 이후에 오는 권태, 이를 모면하려는 자극, 그 이후의 공허감이 정신을 또한 피폐하게 만든다. 이러한 정신의 상태에서도 인생은 정말 아름다운 것이야 라고 느낄 수 있을 까.

상위에 언급한 두 작가는 몇 가지의 불행을 막기 위한 태도에 대해서 언급하고 있는데, 그 중에서 일부 기억에 남는 것으로 지금 그렇게 목매달고 불안해 하고 불행해하는 태도가 원대한 이 우주에서 나라는 존재가 차지하는 것만큼이나 얼마나 보잘것없는 지에 대한 생각의 전환이나, 현실에서의 재화보다 저 세상에서의 재화를 쌓는 부분에 초점을 맞추는 기독교적인 사고가 도움이 될 수 있음을 (내가 이해한 것이 맞다는 가정에) 언급하고 있다. 하지만, 이것이 그리 쉬운 길은 아니다. 물론, 나라는 존재가 이 방대한 우주에 비하면 하잘 것이 없으며, 내가 고민하거나 끊임없이 내 신경을 거슬리며 밤잠을 자지 못하게 하는 그것이 시간이 지나면 왜 그리 고민했었나 할 정도로 미미한 것일 지라도 그 순간에는 대의적인 사고가 되지 않는 것이 인간이다. 또한 기독교적인 인간 역시도 성서를 기반으로 한 이상적인 규율 안에서도 내가 물질적으로 소유하고 있는 부분에 대해서 끊임없이 갈등하는 것이 인간이다. (개인적인 생각으로는) 이것이 인생을 아름답게 만드는 방법이 될 수는 있으나 도 닦는 수준을 원하는 이러한 방법은 끊임없는 자기 최면이나 수양 그리고 노력이 필요하다.

그에 비하면, mental tiring과 같은 불행은 이를 잠시라도 잊을 수 있거나 이를 다소 누그러뜨릴 수 있는, 무언가 다 집어 치우고 몰두할 수 있는 취미의 발굴이 더 쉬운 접근법일 수 있다. 더불어, 러셀도 언급했지만, 직업에 대해서, 몰두할 수 있는 취미도 중요하지만, 그와 마찮가지로 몰두할 수 있는 적절한 직업의 선택 역시 중요하다. 요즘, 청년실업의 증가와 함께 이도 역시 쉽지 않은 가운데, 한비아씨가 어느 TV프로그램에서 언급한 이야기가 가슴을 훔친다. 가슴 떨리는, 가슴 벅차게 만드는 일을 찾는 것, 이것이 가장 좋은 방법이 아닐 까 한다. 아마, 인생이 아름답다라고 느끼고 싶다면 …. “무엇이 내 가슴을 뛰게 하는 가”에 대한 답변을 낼 수 있으며, 그를 행동으로 옮길 수 있는 용기 ….
 
어느 것을 손에 쥘 수 있을 까, 자기 수양과 용기. 아니면 현명해질 때까지 기다릴 것인가. 인생은 진정으로 아름다운가.

ChildEBP RetAddr  Args to Child             

0d41f0d4 7923b543 e0434f4d 00000001 00000000 kernel32!RaiseException+0x53

0d41f12c 7923b4c6 06959590 00000000 0d41f388 mscorsvr!RaiseTheException+0xa0

0d41f154 7923b47a 06959590 00000000 0d41f398 mscorsvr!RealCOMPlusThrow+0x48

0d41f164 79239c8c 06959590 0000002b 00000000 mscorsvr!RealCOMPlusThrow+0xd

0d41f398 792b718e 0000002b 00000000 00000000 mscorsvr!CreateMethodExceptionObject+0x67b

0d41f42c 792b71b2 80004003 00000000 00000000 mscorsvr!RealCOMPlusThrowHRWorker+0xb9

0d41f448 792b731c 80004003 00000000 00000000 mscorsvr!RealCOMPlusThrowHRWorker+0x15

0d41f4d4 792a8552 80004003 00000000 0d41f514 mscorsvr!RealCOMPlusThrowHR+0x168

0d41f4e8 0268435d 00000000 00000000 80004003 mscorsvr!Interop::ThrowExceptionForHR+0x3a

WARNING: Frame IP not in any known module. Following frames may be wrong.

0d41f660 791f6049 00000001 0d41f69c 791f609d 0x268435d

0d41f66c 791f609d 0cafa2d8 0695800c 00000000 mscorsvr!CTPMethodTableCallTargetHelper+0xf

0d41f69c 791fa7f8 0cafa2d8 0695800c 00000000 mscorsvr!CTPMethodTable::CallTarget+0x4e

0d41f6c0 791b2682 0cb06e5c 00000000 00000001 mscorsvr!CRemotingServices::CreateProxyOrObject+0x5f

0d41f730 791b273c 0cb06e5c 0caff013 00000000 mscorsvr!AppDomain::GetOffsetOfSlotsCount+0xa0

0d41f74c 791b7f92 0d41f864 791bdd4e 0d41f7a0 mscorsvr!JIT_NewCrossContext+0x3a

0d41f754 791bdd4e 0d41f7a0 00000000 0d41f778 mscorsvr!CallDescrWorker+0x30

0d41f864 791d5bd5 00b068bb 026e8a10 024547a0 mscorsvr!MethodDesc::CallDescr+0x1b8

0d41f88c 79236659 0d41f8a8 024547a0 0d41fc8c mscorsvr!MethodDesc::Call+0x8e

0d41f8b8 792cec0a 06957e50 0d41f934 02683c9a mscorsvr!CallDefaultConstructor+0x10c

0d41f8c4 02683c9a 0d41f8d0 06957e50 0cafec57 mscorsvr!CRemotingServices::CallDefaultCtor+0xd

또 하나 중요한 사실은 Cross boundary Call임을 보여주는 데, JIT_NewCrossContext 즉, Enterprise Services Component가 호출이 정상적으로 이뤄지지 않았음을 보여준다. 이는 분명 COM+에 등록된 Component의 초기화에 실패했음을 역시 보여주고 있다. Manager Callstack을 더 살펴보자.

0:029> !dumpstack -EE

Thread 29

Current frame:

  ChildEBP RetAddr    Caller,Callee

0d41f51c 0cafd1f5 (MethodDesc 0xcb03410 +0x255 System.EnterpriseServices.Thunk.Proxy.CoCreateObject)

0d41f548 0cafd107 (MethodDesc 0xcb03410 +0x167 System.EnterpriseServices.Thunk.Proxy.CoCreateObject)

0d41f5fc 0cafcd8d (MethodDesc 0xcb03890 +0x7d System.EnterpriseServices.ServicedComponentInfo.HasClassInterface2)

0d41f610 0cafa8a3 (MethodDesc 0xcb015c8 +0xb3 System.EnterpriseServices.ServicedComponentProxyAttribute.CreateInstance)

0d41f654 0cafa320 (MethodDesc 0x24fe618 +0x48 System.Runtime.Remoting.Activation.ActivationServices.IsCurrentContextOK)

0d41f6f0 0caff8f6 (MethodDesc 0xcb07600 +0x6e System.EnterpriseServices.RWHashTableEx.Put)

0d41f738 0caff013 (MethodDesc 0xcb01710 +0x2b AAA.BB.bbCOMPlus..ctor)

0d41f748 0caff1ee (MethodDesc 0xcb068c0 +0x6 AAA.BB.obj11..ctor)

0d41f8d0 0cafec57 (MethodDesc 0x21c9240 +0x7f System.Runtime.Remoting.Proxies.RealProxy.InitializeServerObject)

0d41f8f4 0cafec95 (MethodDesc 0x21c9240 +0xbd System.Runtime.Remoting.Proxies.RealProxy.InitializeServerObject)

0d41f934 0cafe683 (MethodDesc 0xcb02d28 +0x1b System.EnterpriseServices.ServicedComponentProxy.ConstructServer)

0d41f940 0cafe441 (MethodDesc 0xcb02bc8 +0x141 System.EnterpriseServices.ServicedComponentProxy..ctor)

0d41f96c 0cafe0f2 (MethodDesc 0xcb015f8 +0x8a System.EnterpriseServices.ServicedComponentProxyAttribute.System.Runtime.InteropServices.ICustomFactory.CreateInstance)

0d41f994 0cafdda3 (MethodDesc 0x24fe628 +0x4b System.Runtime.Remoting.Activation.ActivationServices.CreateObjectForCom)

0d41fc74 0cafdd24 (MethodDesc 0xcb034a0 +0x6c System.EnterpriseServices.Thunk.Proxy.CallFunction)

0d41fc98 0cafdd24 (MethodDesc 0xcb034a0 +0x6c System.EnterpriseServices.Thunk.Proxy.CallFunction)

0d41fcc0 0cafdc87 (MethodDesc 0xcb05a28 +0x67 System.EnterpriseServices.Internal.AppDomainHelper.System.EnterpriseServices.Internal.IAppDomainHelper.DoCallback)

일단, AAA.BB.bbCOMPlus..ctor Constructor에서 문제가 발생한 것을 보여주는 데, return value를 통해서 진행되고 있는 Assembly code를 살펴볼 필요가 있다.

0:029> ub 0caff013

<Unloaded_mscorwks.dll>+0x22effd:

0cafeffd 47              inc     edi

0cafeffe 40              inc     eax

0cafefff 60              pushad

0caff000 f5              cmc

0caff001 8bce            mov     ecx,esi

0caff003 ff15d814b00c    call    dword ptr [<Unloaded_mscorwks.dll>+0x2314d8 (0cb014d8)]

0caff009 b95c6eb00c      mov     ecx,offset <Unloaded_mscorwks.dll>+0x236e5c (0cb06e5c)

0caff00e e8ef366b6c      call    mscorsvr!JIT_NewCrossContext (791b2702)

실질적으로 문제가 발생한 JIT_NewCrossContext 와 연관된 Class를 찾는 것이 목적이다. 상위의 Assembly code를 보면, JIT_NewCrossContext 를 호출하기 이전에 ecx register에 Keep 하는 뭔가가 있음을 확인할 수 있다. 이는 MethodTable 정보이다.

0:029> !dumpmt 0cb06e5c

EEClass : 0x0cb54568

Module : 0x026dc578

Name: xxxx.M.ConfigurationInit

mdToken: 0x02000011  (c:\winnt\assembly\gac\xxxx\1.2.1.4__0230c138d8d9aa19\xxxx.dll)

BaseSize: 0x28

MethodTable Flags : 0x20c0000

Number of IFaces in IFaceMap : 0x4

Interface Map : 0x0cb06f00

Slots in VTable : 30

그러므로, xxxx.M.ConfigurationInit class의 초기화 실패로 인한 잘못된 포인터 오류가 발생했음을 알 수 있다.

사실 상위의 문제를 Fix하기 위해서는 추가적으로 해당 오류가 발생하기 직전에 발생한 1st chance exception들 중에 해당 Class와 연관 있는 exception을 check 해보는 것이 필요 하다. 아니면, 해당 class의 초기화 실패가 코드의 원인일 수도 있기 때문에 code review로써 문제를 해결할 수도 있을 지 모른다.

Finalizer Thread는 CLR 메모리 덤프에서 볼 수 있는 특이한 Thread 중에 하나이다. 오브젝트가 Garbage Collected 될 때, 오브젝트의 Finalize Method는 Finalizer에 의해서 수행이 된다. 일반적으로 이러한 Finalization이 필요한 오브젝트는 File 이나 Unmanaged Memory와 같은 Unmanaged Resource를 사용하는 오브젝트이며, 필요에 의해 Finalize Method를 구현하여 이와 같은 Unmanaged resource의 누수를 방지하는 역할을 하는 것이 Finalizer Thread이다. 일반적으로 Finalizer Thread를 확인하는 방법은 !threads의 출력으로 다음과 같이 확인할 수 있다.

0:026> !threads

ThreadCount: 12

UnstartedThread: 0

BackgroundThread: 12

PendingThread: 0

DeadThread: 0

                                  PreEmptive   GC Alloc                     Lock    

        ID  ThreadOBJ       State     GC       Context           Domain     Count APT Exception

 16  0xf44 0x000d23e0      0xa220 Enabled  0x06953ce0:0x06954ff4 0x00113b98     1 MTA

 20  0x7bc 0x000d3910      0xb220 Enabled  0x00000000:0x00000000 0x000cd460     0 MTA (Finalizer)

 22  0xf64 0x000ef538   0x1800220 Enabled  0x00000000:0x00000000 0x000cd460     0 MTA (Threadpool Worker)

그리고, 대부분의 메모리 덤프에서는 다음과 같은 Finalizer Thread의 Callstack을 확인할 수 있다.

0:020> kbL

ChildEBP RetAddr  Args to Child             

023ffdf8 7c967d19 7c82202c 00000002 023ffe48 ntdll!KiFastSystemCallRet

023ffdfc 7c82202c 00000002 023ffe48 00000001 ntdll!NtWaitForMultipleObjects+0xc

023ffea4 7c822fbe 00000002 793effc8 00000000 kernel32!WaitForMultipleObjectsEx+0x11a

023ffec0 7926ed87 00000002 793effc8 00000000 kernel32!WaitForMultipleObjects+0x18

023ffee0 792034b2 000002f0 00000000 7922ec48 mscorsvr!WaitForFinalizerEvent+0x5a

023fff24 7922ec3f 00000000 809a1724 7ff97000 mscorsvr!GCHeap::FinalizerThreadStart+0x96

023fffb8 7c82482f 000d3ad8 00000000 00000000 mscorsvr!Thread::intermediateThreadProc+0x44

023fffec 00000000 7922ebfe 000d3ad8 00000000 kernel32!BaseThreadStart+0x34

일반적으로 Finalizer Thread를 쳐다볼 일은 없을 것이다. 하지만, Finalizer Thread의 Blocking으로 인해서 예상치 못한 메모리 누수현상이 발생할 수 있다. 쉽게 isolation 할 수 있는 것은
 

ü  Hang Dump를 몇 차례 수집하였을 때, !finalizequeue의 결과의 추이를 살펴보는 것일 것이다. 계속해서 Finalizequeue 에 오브젝트들이 쌓이고 있다면, Finalizer Thread의 Block을 의심할 수 있다.   

ü  GC가 정상적으로 수행되지 않는 다고 생각될 경우에도 Finalizer Thread를 살펴보는 것이 좋을 것 같다. 일반적으로 메모리 누수의 원인이 되는 오브젝트들이 Reference를 갖고 있지 않는 경우라면, 다음 GC가 수행되었을 때, 메모리가 반환될 것이다. 하지만, 이러한 참조되지 않는 오브젝트가 대량으로 메모리를 차지 하고 있다면, GC의 수행이 그다지 Health한 상태가 아닐 수 있기 때문에 GC Thread와 더불어 Finalizer Thread 역시 확인 대상이 된다.

다음의 Thread Stack은 흥미롭다. Finalizer thread가 맞다. 하지만, EnterCriticalSection에서 Waiting을 하고 있다. 다음의 Managed Callstack 은 임의의 Finalize Method가 처리되고 있는 것이 눈에 띈다. 만일, 지속적으로 이와 같은 Callstack이 Stuck 되고 있다면, 이는 Finalizer Thread가 Block 된 상태로 보면 된다. 해당 Finalize Method와 연관된 CriticalSection Lock 또는 관련 Thread Stack을 Check해보는 것이 우선일 수 있다.

 0:002> kbL

ChildEBP RetAddr  Args to Child             

00c9f9fc 7c967d29 7c97d266 000011d8 00000000 ntdll!KiFastSystemCallRet

00c9fa00 7c97d266 000011d8 00000000 00000000 ntdll!NtWaitForSingleObject+0xc

00c9fa3c 7c97d2b1 000011d8 00000002 04b2b008 ntdll!RtlpWaitOnCriticalSection+0x1a3

00c9fa5c 608fa5af 08ddbf68 00c9fcc4 61ccc1ae ntdll!RtlEnterCriticalSection+0xa8

WARNING: Stack unwind information not available. Following frames may be wrong.

00c9fa68 61ccc1ae 006e2628 0487af7c 00000000 oracore10!sltsmna+0xf

00c9fcc4 61ccb998 08b60128 00000004 00000000 OraClient10!kpufhndl0+0x80e

00c9fcd8 61c2602c 08b60128 00000004 00c9fcf8 OraClient10!kpufhndl+0x10

00c9fce8 1000706c 08b60128 00000004 00c9fd7c OraClient10!OCIHandleFree+0x1a

00c9fd9c 7c966f69 00c9fe30 79215bdd 00c9fe20 oci!OCIHandleFree+0x18

00c9fda4 79215bdd 00c9fe20 7921d108 ffffffff ntdll!ZwDelayExecution+0xc

00c9fe30 79215ca5 0167b394 0015e1e0 0014c698 mscorwks!MethodTable::CallFinalizer+0xee

00c9fe44 791e0984 0167b394 7c822311 00000000 mscorwks!CallFinalizer+0x84

00c9fedc 791b997b 0167b394 00000000 00000000 mscorwks!FinalizeAllObjects+0xd5

00c9ff24 791c94b4 00000000 809a1724 7ffdb000 mscorwks!GCHeap::FinalizerThreadStart+0xc2

00c9ffb8 7c82482f 0015e398 00000000 00000000 mscorwks!Thread::intermediateThreadProc+0x44

00c9ffec 00000000 791c9473 0015e398 00000000 kernel32!BaseThreadStart+0x34

0:002> !dumpstack -EE

Thread 2

Current frame:

  ChildEBP RetAddr    Caller,Callee

00c9fd28 0393d63f (MethodDesc 0x320be10 +0xf System.Data.OracleClient.TracedNativeMethods.OCIHandleFree)

00c9fd34 0393bb47 (MethodDesc 0x320c1f8 +0xf7 System.Data.OracleClient.OciHandle.Dispose)

00c9fd7c 00879c75 (MethodDesc 0x320c188 +0x1d System.Data.OracleClient.OciHandle.Finalize)

ChildEBP RetAddr  Args to Child             

0012ef08 79f97065 e0434f4d 00000001 00000001 kernel32!RaiseException+0x53

0012ef68 7a0945a4 0179a680 00000000 00000000 mscorwks!RaiseTheExceptionInternalOnly+0x226

*** WARNING: Unable to verify checksum for mscorlib.ni.dll

0012f02c 7952257c 0012f000 00000000 0179a610 mscorwks!JIT_Throw+0xd0

상위의 경우는 아래와 같은 Exception이 발생한 것이다.

0:000> .loadby sos mscorwks

0:000> !do 0179a680

Name: System.UnauthorizedAccessException

MethodTable: 7915fc6c

EEClass: 791eb60c

Size: 72(0x48) bytes

 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

Fields:

      MT    Field   Offset                 Type VT     Attr    Value Name

790fa3e0  40000b5        4        System.String  0 instance 00000000 _className

79109208  40000b6        8 ...ection.MethodBase  0 instance 00000000 _exceptionMethod

790fa3e0  40000b7        c        System.String  0 instance 00000000 _exceptionMethodString

790fa3e0  40000b8       10        System.String  0 instance 017a23f4 _message

79113dfc  40000b9       14 ...tions.IDictionary  0 instance 00000000 _data

790fa9e8  40000ba       18     System.Exception  0 instance 00000000 _innerException

790fa3e0  40000bb       1c        System.String  0 instance 00000000 _helpURL

790f9c18  40000bc       20        System.Object  0 instance 00000000 _stackTrace

790fa3e0  40000bd       24        System.String  0 instance 00000000 _stackTraceString

790fa3e0  40000be       28        System.String  0 instance 00000000 _remoteStackTraceString

790fed1c  40000bf       34         System.Int32  1 instance        0 _remoteStackIndex

790f9c18  40000c0       2c        System.Object  0 instance 00000000 _dynamicMethods

790fed1c  40000c1       38         System.Int32  1 instance -2147024891 _HResult

790fa3e0  40000c2       30        System.String  0 instance 00000000 _source

790fe160  40000c3       3c        System.IntPtr  1 instance        0 _xptrs

790fed1c  40000c4       40         System.Int32  1 instance -532459699 _xcode

해당 Exception Object는 흥미로운 정보를 가지고 있다. 예를 들어, _HResult 값을 확인해 보면, 보기에 눈에 익숙하지 않지만, 다음과 같이 변환해 보면, 다소 우리에게 익숙한 HRESULT 값을 볼 수 있다.

0:000> ? -0n2147024891

Evaluate expression: -2147024891 = 80070005

즉, 해당 Exception은 Access Denied Error와 관련 있음을 알 수 있다.

그리고, _xcode 를 살펴보면, 그냥 .NET Exception임을 보여준다.

0:000> ? -0n532459699

Evaluate expression: -532459699 = e0434f4d

또 다른 다음의 Exception의 예를 들어 보면,

0:000> !do 0c48dfa8

Name: System.NullReferenceException

MethodTable 0x03211a3c

EEClass 0x03201590

Size 64(0x40) bytes

GC Generation: 0

mdToken: 0x020000af  (c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll)

FieldDesc*: 0x00000000

        MT      Field     Offset                 Type       Attr      Value Name

0x008d575c 0x400001d      0x4                CLASS   instance 0x00000000 _className

0x008d575c 0x400001e      0x8                CLASS   instance 0x00000000 _exceptionMethod

0x008d575c 0x400001f      0xc                CLASS   instance 0x00000000 _exceptionMethodString

0x008d575c 0x4000020     0x10                CLASS   instance 0x01066ab8 _message

0x008d575c 0x4000021     0x14                CLASS   instance 0x00000000 _innerException

0x008d575c 0x4000022     0x18                CLASS   instance 0x00000000 _helpURL

0x008d575c 0x4000023     0x1c                CLASS   instance 0x0c48dfe8 _stackTrace

0x008d575c 0x4000024     0x20                CLASS   instance 0x00000000 _stackTraceString

0x008d575c 0x4000025     0x24                CLASS   instance 0x00000000 _remoteStackTraceString

0x008d575c 0x4000026     0x2c         System.Int32   instance 0 _remoteStackIndex

0x008d575c 0x4000027     0x30         System.Int32   instance -2147467261 _HResult

0x008d575c 0x4000028     0x28                CLASS   instance 0x00000000 _source

0x008d575c 0x4000029     0x34         System.Int32   instance 83683696 _xptrs

0x008d575c 0x400002a     0x38         System.Int32   instance -1073741819 _xcode

-----------------

Exception 0c48dfa8 in MT 03211a3c: System.NullReferenceException

_message: 개체 참조가 개체의 인스턴스로 설정되지 않았습니다.

_stackTrace:

04dece25 [DEFAULT] String ttt.ttt.ttt.1(SZArray Object)

04fcee50

00fbee70

00e3c34c [DEFAULT] [hasThis] Class System.Runtime.Remoting.Messaging.IMessage ttt.ttt.ttt.cls.Invoke(Class System.Runtime.Remoting.Messaging.IMessage)

04fcee6c

00fbee20

흥미롭게도 _stactTrace 라는 정보는 0x0c48dfe8 address에 Exception이 발생한 시점의 stack이 dumping된 것으로 보면 된다. 그에 대한 정보가 상위의 Exception Object를 View 할 때 하단 부분에 첨부된 것을 볼 수 있기도 하다. 해당 Callstack이 Managed 이기 때문에 dds (또는 ddp) 명령은 아래와 같이 의미가 없을 수 있겠다.

0:000> dds 0x0c48dfe8

0c48dfe8  00c40274

0c48dfec  00000018

0c48dff0  04dece25

0c48dff4  04fcee50

0c48dff8  00fbee70

0c48dffc  00e3c34c

0c48e000  04fcee6c

0c48e004  00fbee20

0c48e008  00000000

하지만, 필요하다면, SOS 명령의 ip2md 를 이용해서 역시 문제 발생시의 Method 정보를 일일이 추출할 수 있다.

0:000> !ip2md 04dece25

MethodDesc: 0x00fbee70

Jitted by normal JIT

Method Name : [DEFAULT] String ttt.ttt.ttt.1(SZArray Object)

MethodTable 0xfbeeac

Module: 0x1c3980

mdToken: 0x060000b9 (c:\windows\assembly\gac\tttxxxx\2.1.0.0__de06f536f526478c\ttt.dll)

Flags : 0x10

Method VA : 0x04decd98

해당 Exception의 _xcode 정보를 보면,

0:000> ? -0n1073741819

Evaluate expression: -1073741819 = c0000005

이는 Access Violation 에 의한 Exception이 유발되었음을 알려준다. 보통 AV는 Exception record 를 keep 하기도 하는 데, 이는 _xptrs 가 가지고 있곤 한다. 이는 kernel32!EXCEPTION_POINTERS 구조체를 가리킨다.

0:000> ? 0n83683696

Evaluate expression: 83683696 = 04fce970

0:000> dc 04fce970 l2

04fce970  00000018 00000000                    ........

상위의 Exception에서는 Exception Records가 0x18 그리고, Context 는 NULL 로 정상적으로 Keep 되지 않았지만, 해당 Context가 유용하다면, .cxr <context address> 을 통해 AV가 발생한 Context로 이동하여 Debugging할 수 있을 것이다. 

COM+ 는 Transaction 속성을 지정할 수 있는 데, 다양한 Transaction 시나리오를 위해서 5가지의 Transaction 속성을 지정할 수 있다. 몇 가지를 비교해서 설명하면,

Disabled 와 Not supported 속성을 먼저 비교할 수 있다. 이들은 엄밀히 말하면 Transaction에서 벗어나 있다. 그러므로, 기존에 해당 Component를 호출하는 이전에 이미 Transaction이 존재한다면, Not supported의 경우는 해당 Transaction context를 하위의 Component로 흘려 보내지 않는 다. 하지만, Disabled는 이미 존재하는 Transaction Context와 무관하지만, 하위의 Component에 Transaction Context를 흘러 보냄으로써 Transaction Context를 Share한다. 하지만, 이들 둘 다 해당 Component에서는 Transaction이 무관하므로 Transaction의 Complete/Abort 에 대한 voting을 할 수 없다.

오히려 Disabled와 Supported의 경우는 동일하게 Transaction Context를 Share하는 경우로, 이미 존재하는 Transaction을 하위 Component에 흘려 보낼 수 있다. Disabled가 자신은 Transaction Context의 존재와 상관없이 transaction과 무관하다면, Supported는 Transaction Context가 존재할 경우에 Transaction을 탈 수 있으며, 존재하지 않으며, Transaction을 타지 않고 수행된다. 그러므로, Disabled 와는 달리 Transaction에 대한 Voting이 가능하다.

Required 와 Required New를 비교해보자. 둘 다 Transaction을 반드시 타는 경우이므로, Transaction에 대한 Voting을 둘 다 가능/필요하다. 하지만, Required는 기존에 Transaction이 이미 존재한다면, 해당 transaction을 타지만, 어떠한 transaction이 존재하지 않는 다면, 스스로 Root transaction 즉, New Transaction을 만든다. 하지만, Required New의 경우는 기존의 Transaction의 존재 여부와 상관없이 항상 Root transaction이 된다. COM+가 Nested Transaction을 지원하지 않기 때문에 새로운 Transaction으로 분기되는 경우가 생긴다면, 각각의 Transaction은 별개의 Transaction으로 간섭하지 않는 다는 것도 명심해야겠다.

만일, Transactional 속성이 Disabled인 Component에서 Exception이 발생하였다면?

상위 내용대로라면, 해당 Component에서의 SetAbort는 기존의 transaction에 영향을 주지 않는 것이 맞을 것이다. 하지만, Exception을 Propagation 하여 Transactional Component(Disabled나 Not supported가 아닌)안에서 명시적으로 SetAbort를 할 것인지, SetComplete을 할 것인지를 결정할 수 있겠다. 복잡한 것이 이 문제가 Disabled Component 이전의 Transactional Component뿐만이 아니라 Exception handling여부에 따라 미치게 되는 Disabled Component 하위에 transactional Component가 존재할 수 있기 때문에 정상적인 Exception handling외에 각 상.하위 Component의 Transactional Voting역시 프로그램 흐름상 고려되어 질 필요가 있을 지도 모르겠다.

0:100> !locks

CritSec +14ce60 at 0014ce60

WaiterWoken        No

LockCount          134

RecursionCount     1

OwningThread       162c

EntryCount         0

ContentionCount    86

*** Locked

CritSec +15d558 at 0015d558

WaiterWoken        No

LockCount          2

RecursionCount     1

OwningThread       8a4

EntryCount         0

ContentionCount    2

*** Locked

2개의 Lock이 보이므로, 이것들이 서로서로 deadlock을 유발하겠구나 하고 쉽게 생각했지만, 그렇지 않았다. 일단, 134개의 lock을 잡고 있는 162c의 Thread는 GC Thread였다.

0:100> ~~[162c]s

eax=00000001 ebx=04fce8c0 ecx=002381e8 edx=7c96ed64 esi=04fce8c4 edi=7ffd4000

eip=7c96ed64 esp=04fce874 ebp=04fce91c iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!KiFastSystemCallRet:

7c96ed64 c3              ret

0:014> kb

ChildEBP RetAddr  Args to Child             

04fce870 7c962104 7c82716b 00000002 04fce8c0 ntdll!KiFastSystemCallRet

04fce874 7c82716b 00000002 04fce8c0 00000001 ntdll!NtWaitForMultipleObjects+0xc

04fce91c 7c821095 00000002 04fcea5c 00000000 kernel32!WaitForMultipleObjectsEx+0x11a

04fce938 79248be3 00000002 04fcea5c 00000000 kernel32!WaitForMultipleObjects+0x18

04fceb70 791e0723 00000002 00000000 00000000 mscorwks!Thread::SysSuspendForGC+0x248

04fceb88 792144f9 00000001 00000000 00000000 mscorwks!GCHeap::SuspendEE+0xcf

04fceba4 7924199e 00000000 00000000 00000e44 mscorwks!GCHeap::GarbageCollectGeneration+0x103

04fcebd4 791b3868 00238a08 00000e44 00000000 mscorwks!gc_heap::allocate_more_space+0x13a

04fcedf8 791b300a 00238a08 00000e44 00000000 mscorwks!GCHeap::Alloc+0x5f

04fcee0c 791dd118 00000e44 00000000 00000000 mscorwks!Alloc+0x3a

04fcee2c 791dd0b9 00bd0088 0000071c 00000000 mscorwks!FastAllocatePrimitiveArray+0x45

04fceeac 00bc1336 00000000 0000071c 0c67ab58 mscorwks!JIT_NewArr1+0xbb

WARNING: Frame IP not in any known module. Following frames may be wrong.

00000000 00000000 00000000 00000000 00000000 0xbc1336

이것은 아마도 Memory Allocation중에 적정한 Size의 Memory를 할당받지 못했나 보다. 하여, GC가 수행되기 위해 EE를 Suspend 를 하고 있다. 만일, 이 Thread가 진행되지 않는 다면, 이는 Suspend 되지 않는 Thread가 존재할 것이라 믿는 다. 그 전에 대부분의 Thread가 아래와 같은 Thread와 동일한 형태였다.

0:014> ~100s

eax=000019d6 ebx=00000000 ecx=00000000 edx=630d5cb8 esi=0014ce60 edi=000005b8

eip=7c96ed64 esp=10c0f9bc ebp=10c0f9f8 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!KiFastSystemCallRet:

7c96ed64 c3              ret

0:100> kb

ChildEBP RetAddr  Args to Child             

10c0f9b8 7c962114 7c97972f 000005b8 00000000 ntdll!KiFastSystemCallRet

10c0f9bc 7c97972f 000005b8 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc

10c0f9f8 7c979640 00000000 00000004 0000000a ntdll!RtlpWaitOnCriticalSection+0x19c

10c0fa18 791b6ffc 0014ce60 10c0fa4c 79268960 ntdll!RtlEnterCriticalSection+0xa8

10c0fa24 79268960 0014ce60 00000000 0fdc43c8 mscorwks!EE_EnterCriticalSection+0xc

10c0fa38 791b48f8 7c828ce5 0fdc43c8 7c82bccd mscorwks!BaseCrst::Enter+0x8a

10c0fa4c 791d09e8 00000000 00000001 0fdc43c8 mscorwks!ThreadStore::LockThreadStore+0x9d

10c0fa60 791d0abb 0fdc43c8 00000000 7c82bbcd mscorwks!ThreadStore::AddThread+0xd

10c0fa88 7929c0de 0020de28 10c0fb48 7931712e mscorwks!SetupThread+0x103

10c0fa94 7931712e 00000000 0020de28 0020de28 mscorwks!SetupThreadPoolThread+0x15

10c0fb48 79317611 0017cd48 00000001 00000001 mscorwks!AddTimerCallbackEx+0x16

10c0fb5c 792eebc6 0017cd48 00000001 792eebb7 mscorwks!AddTimerCallback+0x10

10c0fb70 792ee6ca 0020de28 0512fe38 793fa170 mscorwks!ThreadpoolMgr::AsyncTimerCallbackCompletion+0xf

10c0fb84 792ee8c3 0512fe38 00000000 792ee79a mscorwks!ThreadpoolMgr::ExecuteWorkRequest+0x19

10c0fba4 792edfdb 00000000 00000014 10c0fbdc mscorwks!ThreadpoolMgr::WorkerThreadStart+0x129

10c0ffb8 7c8260b9 001a8488 00000000 00000000 mscorwks!ThreadpoolMgr::intermediateThreadProc+0x44

10c0ffec 00000000 792edf97 001a8488 00000000 kernel32!BaseThreadStart+0x34

0:100> dc 0014ce60

0014ce60  0014cf80 fffffde6 00000001 0000162c  ............,...

0014ce70  000005b8 00000000 0014cfa8 ffffffff  ................

0014ce80  00000000 00000000 00000000 00000000  ................

0014ce90  0015d610 0014ce90 00238a40 00000008  ........@.#.....

0014cea0  00000000 00000006 00000000 00000001  ................

0014ceb0  00000000 00000000 00000000 00000000  ................

0014cec0  00000000 002389d0 0000162c 00000111  ......#.,.......

0014ced0  00100010 000c01b6 003a0063 0077005c  ........c.:.\.w.

ntdll!RtlEnterCriticalSection Function이 우리가 흔히 알고 있는 EnterCriticalSection 함수와 유사하다면, 첫번째 파라메터는 Critical Section Object일 것이다. Binary 를 살펴보면, 0xc offset에 162c 라는 값이 들어 온다. 이미 살펴 본봐 이는 !lock에서 보여주었던 GC Thread의 ThreadID와 동일하다. 아마도, 해당 Critical Section의 Owner를 보여주는 것으로 보인다.

결국, GC Thread가 Suspend Wait 하고 있는 이유를 밝히는 것이 중요하다. 아쉽게도 !lock에서 보여준 2번째 Thread의 Owner는 Orphan Thread임이 밝혀졌다.

0:100> ~~[8a4]d

             ^ Illegal thread error in '~~[8a4]d'

0:100> ~ <<< ALL thread를 살펴볼 수 있으나, ThreadID가 8a4 인 놈을 찾을 수 없다.

그리고, 중요한 것은 다음.

0:100> !threads

Loaded Son of Strike data table version 5 from "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll"

ThreadCount: 8

UnstartedThread: 0

BackgroundThread: 6

PendingThread: 0

DeadThread: 1

                                  PreEmptive   GC Alloc                     Lock    

        ID  ThreadOBJ       State     GC       Context           Domain     Count APT Exception

  0 0x6928 0x0015d5a0      0xa020 Enabled  0x00000000:0x00000000 0x0014c130     0 MTA

  2  0x86c 0x00155508      0xb220 Enabled  0x00000000:0x00000000 0x0014c130     0 MTA (Finalizer)

  3  0x750 0x00194cf0      0x1220 Enabled  0x0c484a6c:0x0c486140 0x0014c130     0 Ukn

  5 0x70fc 0x001820d8   0x2001220 Enabled  0x00000000:0x00000000 0x0014c130     0 Ukn

 10 0x51f8 0x001a6c48    0x800222 Disabled 0x0c3a7c60:0x0c3a7c70 0x0014c130     0 MTA (Threadpool Completion Port)

XXX      0 0x001bbfc0    0x800820 Enabled  0x00000000:0x00000000 0x0014c130     1 MTA (Threadpool Completion Port)

 13 0x63e8 0x002381e8    0x800222 Disabled 0x0c489bf0:0x0c48a140 0x0014c130     0 MTA (Threadpool Completion Port)

 14 0x162c 0x002389d0    0x800220 Disabled 0x0c6ae3d8:0x0c6af044 0x0014c130     1 MTA (GC) (Threadpool Completion Port)

보면, PreEmptive GC에 Enabled 되지 않은 Thread가 GC Thread 포함해서 3개가 존재한다. 14번 Thread인 GC Thread는 다른 모든 Thread가 Suspend될 때까지 기다릴 터이다. 그럼, 10번, 13번 Thread가 왜 Disabled 인지 확인할 필요가 있다.

0:100> ~10s

eax=00003a24 ebx=00000000 ecx=00000000 edx=5dc101c9 esi=0015d558 edi=00000498

eip=7c96ed64 esp=0488df7c ebp=0488dfb8 iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246

ntdll!KiFastSystemCallRet:

7c96ed64 c3              ret

0:010> kb

ChildEBP RetAddr  Args to Child              

0488df78 7c962114 7c97972f 00000498 00000000 ntdll!KiFastSystemCallRet

0488df7c 7c97972f 00000498 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc

0488dfb8 7c979640 00000000 00000004 0000000a ntdll!RtlpWaitOnCriticalSection+0x19c

0488dfd8 791b6ffc 0015d558 0488e008 79268960 ntdll!RtlEnterCriticalSection+0xa8

0488dfe4 79268960 0015d558 0488e15c 0488e15c mscorwks!EE_EnterCriticalSection+0xc

0488dff8 79254d88 0488e15c 0488e140 0488e044 mscorwks!BaseCrst::Enter+0x8a

0488e008 7921d09b 0488e140 0488e6b0 0488e15c mscorwks!CPFH_HandleManagedFault+0x61

0488e044 7921d135 0488e140 0488e6b0 0488e15c mscorwks!GetPrevSEHRecord+0x703

0488e05c 7c96eeca 0488e140 0488e6b0 0488e15c mscorwks!COMPlusFrameHandler+0x3d

0488e080 7c96ee9b 0488e140 0488e6b0 0488e15c ntdll!ExecuteHandler2+0x26

0488e128 7c96ecd6 04888000 0488e15c 0488e140 ntdll!ExecuteHandler+0x24

0488e128 04dece25 04888000 0488e15c 0488e140 ntdll!KiUserExceptionDispatcher+0xe

WARNING: Frame IP not in any known module. Following frames may be wrong.

0488e424 0488e650 0c3a7468 0c3a7504 0c3a4af8 0x4dece25

00000000 00000000 00000000 00000000 00000000 0x488e650

눈에 띄는 것은 KiUserExceptionDispatcher . (http://byung.egloos.com/4710539) 이것은 Exception이 발생한 경우이다. 해당 함수의 Stack을 살펴보면, 아래와 같은 몇몇 정보를 얻을 수 있다.

0:010> dc 0488e128

0488e128  0c3a7ac8 7c96ecd6 04888000 0488e15c  .z:....|....\...

0488e138  0488e140 0488e15c c0000005 00000000  @...\...........  <<< c0000005: Access Violation

0488e148  00000000 04dece25 00000002 00000000  ....%........... <<< 04dece25: Exception Address

0488e158  00000000 0001003f 00000000 00000000  ....?...........  <<< 1003f Context Flags

0488e168  00000000 00000000 00000000 00000000  ................

0488e178  ffff027f ffff4020 ffffffff 00bc4c08  .... @.......L..

0488e188  00ca001b 0488e6d8 ffff0023 00000000  ........#.......

0488e198  00000000 00000000 00000000 00000000  ................

결국, 해당 Thread는 04dece25 에서 Access Violation 에 대한 Exception으로 인해 GC에 의해 Suspend 되지 않은 것으로 보인다. 이는 Orphan Thread와 관련이 있을 수도 있다. 임의의 Orphan Thread (Thread ID:8a4)가 Critical Section Lock을 잡고 Terminated 되었기 때문에 해당 Exception Thread에서 Critical Section Lock이 걸려있을 수도 있다. 그리고, 추가적으로 13번 Thread 역시 10번 Thread와 동일한 Exception Thread이다.

0:013> kb

ChildEBP RetAddr  Args to Child             

00d4e5f0 7c962114 7c97972f 00000498 00000000 ntdll!KiFastSystemCallRet

00d4e5f4 7c97972f 00000498 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc

00d4e630 7c979640 00000000 00000004 0000000a ntdll!RtlpWaitOnCriticalSection+0x19c

00d4e650 791b6ffc 0015d558 00d4e680 79268960 ntdll!RtlEnterCriticalSection+0xa8

00d4e65c 79268960 0015d558 00d4e7d4 00d4e7d4 mscorwks!EE_EnterCriticalSection+0xc

00d4e670 79254d88 00d4e7d4 00d4e7b8 00d4e6bc mscorwks!BaseCrst::Enter+0x8a

00d4e680 7921d09b 00d4e7b8 00d4ed28 00d4e7d4 mscorwks!CPFH_HandleManagedFault+0x61

00d4e6bc 7921d135 00d4e7b8 00d4ed28 00d4e7d4 mscorwks!GetPrevSEHRecord+0x703

00d4e6d4 7c96eeca 00d4e7b8 00d4ed28 00d4e7d4 mscorwks!COMPlusFrameHandler+0x3d

00d4e6f8 7c96ee9b 00d4e7b8 00d4ed28 00d4e7d4 ntdll!ExecuteHandler2+0x26

00d4e7a0 7c96ecd6 00d4d000 00d4e7d4 00d4e7b8 ntdll!ExecuteHandler+0x24

00d4e7a0 04dece25 00d4d000 00d4e7d4 00d4e7b8 ntdll!KiUserExceptionDispatcher+0xe

WARNING: Frame IP not in any known module. Following frames may be wrong.

00d4ecc8 00e3b502 00d4ed10 00fbcda8 00d4ed28 0x4dece25

00000000 00000000 00000000 00000000 00000000 0xe3b502

0:013> dc 00d4e7a0

00d4e7a0  00d4ecc8 7c96ecd6 00d4d000 00d4e7d4  .......|........

00d4e7b0  00d4e7b8 00d4e7d4 c0000005 00000000  ................

00d4e7c0  00000000 04dece25 00000002 00000000  ....%...........  << Exception Address가 10번 Thread와 동일한 위치!!

00d4e7d0  00000000 0001003f 00000000 00000000  ....?...........

00d4e7e0  00000000 00000000 00000000 00000000  ................

00d4e7f0  ffff027f ffff0000 ffffffff 00bc4c08  .............L..

00d4e800  00ca001b 00d4ecd8 ffff0023 00000000  ........#.......

00d4e810  00000000 00000000 00000000 00000000  ................

그러므로, Orphan Thread 역시 이와 같은 Exception에 문제가 되는 것은 아닌 지 의심해 본다. 결국, 해당 GC suspend Hang은 Exception에 대한 Fix가 우선적으로 처리되는 것이 필요하며, Orphan Thread를 위해 1^st chance exception에 대한 추가적인 메모리 덤프를 분석해 볼 필요도 있을 지 모른다.

추가적으로 Exception Address의 Assembly code를 !u (해당 Thread는 managed thread stack을 보여줬다.) 를 통해 확인해 볼 필요가 있겠다. 여기서 또한, .cxr 을 이용하여 (Context Flags의 address pointer 를 이용) Context switch 하여 Exception 발생 Thread Stack으로 이동할 필요도 있을 것이다. 이하 생략한다. 단지, 해당 Process의 hang 상태를 확인하는 과정으로써 Thread Stack의 Pattern이나 분석 과정을 흩어보는 것으로 마무리 한다.

AppInit_DLLs의 구조는 일반적으로 API hooking의 mechanism으로 사용되었던 구조이다. 해당 레지스트리 키(AppInit_DLLs:REG_SZ)는 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows 에서 확인할 수가 있는 데, 이는 User32.dll의 DLL_PROCESS_ATTACH과정에서 LoadLibrary() 함수를 사용하여 load 된다. 그러므로, 해당 Registry에 설정된 DLL path는 user32.dll을 사용하는 모든 Application에 의해서 load되므로, DLL injection의 기능으로 사용되어 왔다. 이에 따라서 많은 malware가 이러한 mechanism을 사용하는 바, Dead Lock이나 Crash의 문제가 되었었고, performance에도 영향을 미치게 됨에 따라서 Win7에서는 일부 수정이 있게 되었다.

사실 Windows Vista 에서 부터 AppInit_DLLs 구조는 default 가 disable 이다. 이러한 Default 설정은 Win7에서도 마찮가지이며, 이외에도 다음의 표와 같이 일부 수정된 기능이 존재한다.

상위의 표를 보면 알겠지만, AppInit_DLLs 를 원천적으로 Disable 할 수 있다. 그리고, enable이 된다 하더라도 Code-signed DLL만을 Load하게끔 구성할 수 있다. 이미 짐작하겠지만, AppInit_DLLs를 Application Compatibility의 이유로 인하여 사용해야만 한다면, Recommendation으로는 code-signed DLLs만을 Load하도록 하는 것이 될 것이다.

DLL을 Code-sign하기 위해서는 Digital Signature를 Binary에 embedding 해야 할 것이며, 이는 아래와 같은 절차를 따르게 된다.

ü  /integritycheck linker option을 가지고 DLL을 Link 한다. 이는 Visual Studio 2005/2008에서 지원한다. 이는 dumpbin /headers <dllname.dll> 을 통해 dumping된 data에서 Check integrity 가 포함되었는지를 확인함으로써 verify할 수 있다.

ü  DLL은 /ph (page-hash) option을 가지고 signed되어야 한다. 또한, /t (timestamp) option을 가지고 sign함으로써 code signing certificate의 expiring에 대해서 보호될 수 있다. 그리고, release시에는 반드시 /ac option을 사용하여 cross-certificate에 대한 참조가 가능하도록 한다. 이는 signing code path가 windows kernel에 존재할 때 필요하다.

다음은 SignTool을 이용하여 DLL을 sign 하는 예이다.

·         Test-signing example:

Signtool sign /v /ph /s My /n Contoso.com(Test) /t http://timestamp.verisign.com/scripts/timestamp.dll DLLname.dll

·         Release-signing example:

Signtool sign /v /ph /ac MSCV-VSClass3.cer /s my /n contoso.com /t http://timestamp.verisign.com/scripts/timestamp.dll DLLname.dll

참조 및 발췌: http://www.microsoft.com/whdc/driver/install/AppInit-Win7.mspx

이벤트로그에 오류라고 뜨면 일반적으로 Event ID와 대상 프로그램의 이름 또는 관계된 Component 명, 그리고 Description 등을 확인할 수 있으며, 이를 가지고 Research가 이뤄진다. 하지만, 간혹 Detail 한 Debugging을 위해 문제시점의 메모리 덤프를 얻어서 Callstack등을 확인할 경우가 필요하다. 이 경우에는 Event Log에 reporting 하는 Function인 advapi32!ReportEventW(또는 ReportEventA) 에 Breakpoint를 걸어서 메모리 덤프를 수집하는 것이 유용할 때가 있다. DebugDiag를 사용하는 경우에 편리한데, 아래와 같이 Crash rule에서 추가적으로 지정해 주면 될 듯 하다.

Debug Diag의 Crash Rule에 Advanced Configuration을 줄 수 있는 데, 해당 설정 중에 Breakpoints... 라는 메뉴가 있다.