\r\n0:008:x86> !wow64exts.info\r\n...\r\nTEB32: 0x7efa0000\r\n0:008:x86> dd 0x7efa0000+0xf80 L1\r\n7efa0f80 006cf638\r\n0:008:x86> dd 0x6cf638+0x0c L1\r\n006cf644 00000143\r\n<\/pre>\nUsing some more Win32 knowledge, I happen to know that the TEB is also pointed to by the Frame Segment pointer. I can use this information, the POI() debugger macro, and my ability to count to 0x0c to reduce this operation to a single quick command.<\/p>\n
\r\n0:008:x86> dd poi(fs:f80)\r\n006cf638 00000000 00000000 00000000 00000143\r\n<\/pre>\nIn these flags, if the bits 0x140 are present, the thread is in the MTA. If the bits 0x080 are present, the thread is an STA. If you get ????????, this means that CoInitialize() has not been called. The flags here are 0x143, indicating MTA. So our thread here is MTA, trying to call an STA. Lets look further into the backtrace to see which thread this is and where my code ends and OLE32 begins.<\/p>\n
\r\n0:008:x86> k\r\nChildEBP RetAddr\r\n...\r\n04daff08 00510119 ScriptDPC!ScriptHost.TScriptHostImpl.Unlock+0x6\r\n04daff30 0054a986 image00000000_00400000!DPCHandler.TDPCHandler.DoShutdown+0x35\r\n04daff74 004055e6 image00000000_00400000!MsgConBase.TMsgConBase.ActionShutdown+0x36\r\n04daff88 76213677 image00000000_00400000!System.ThreadWrapper+0x2a\r\n<\/pre>\nThe last bits of my code are in the ScriptDPC dll, so I’ll set a breakpoint in the Unlock method to step through and see what’s going on.<\/p>\n
\r\n0:008:x86> bp ScriptDPC!ScriptHost.TScriptHostImpl.Unlock\r\nSyntax: Module Unit Class Method\r\n<\/pre>\nUse bp to create a breakpoint, bl to list them, and bc to remove (clear) one. Single stepping through the function shows that while clearing up the script context, global COM objects referenced by the script are getting released. Hrm, so it seems one of our COM objects is being Release()d by this thread but it was created by an STA so OLE is being nice and trying to RPC to that thread to release the interface. All inter-apartment calls are considered RPC regardless of their activation context, be they in-process, out-of-process, or on another machine activated by DCOM\/COM+. Looking through all of my threads using the method above, I see only one is an STA, the main thread. So what I am probably looking for is the main thread creating a COM object in my script and not releasing it, which gets deferred until the script context is deleted.<\/p>\n
To find where this occurs is a bit more tricky, so I examine the points where the UI might interface to my scripting component. While poking around examining the interactions, I notice this DLL load trace coming up in the debugger when I execute a context menu a certain component:<\/p>\n
\r\nC:\\Windows\\SysWOW64\\RpcRtRemote.dll\r\nc:\\IE\\DPCs\\Test\\DBServices.dll\r\n<\/pre>\nThe first line there indicates that the RPC engine is being loaded into my process. This creates an MTA thread and a pool of worker threads to service method invokations for objects and is a dead giveaway that the UI’s STA thread has just created a free-threaded object, the calls to which must be marshalled cross-apartment. Some quick tracing through the source code turned up this bit of code being called from the main thread:<\/p>\n
\r\nprocedure TScriptDPCBase.ScriptScriptObjectsNeeded(Sender: TObject);\r\nbegin\r\n RegisterScriptObject('IEProxy', IEProxy);\r\n\r\n if not Assigned(FDBServices) then\r\n FDBServices := CoCDataBaseServices.Create;\r\n RegisterScriptObject('DBServices', FDBServices);\r\nend;\r\n<\/pre>\nCDataBaseServices is flagged as tmFree. There’s our MTA object. A little rearranging moved the CDataBaseServices creation to the initialization of the script thread, make sure it isn’t being accessed by the UI, and lockup solved.<\/p>\n","protected":false},"excerpt":{"rendered":"
While the Delphi debugger is quite good, there are some instances when it isn’t quite good enough. Your application is crashing remotely The worst place for an application to fail is when there is no debugger available. Usually these problems can be corrected via the “Works Fine Here” solution. Unfortunately most bug-tracking systems lack this […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"_links":{"self":[{"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/18"}],"collection":[{"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=18"}],"version-history":[{"count":18,"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/18\/revisions"}],"predecessor-version":[{"id":57,"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/18\/revisions\/57"}],"wp:attachment":[{"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=18"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=18"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/capnbry.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=18"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"Delphi](\"http:\/\/capnbry.net\/blog\/wp-content\/uploads\/2010\/05\/delphisetup.png\" "\\"Delphi")
<\/a>![\"Symbol](\"http:\/\/capnbry.net\/blog\/wp-content\/uploads\/2010\/05\/symbolpath.png\" "\\"Symbol")
<\/a>