Thank you for you reply. Yes, I was using MC++ and, therefore, there obviously were unmanaged -> managed calls. We've patched our unit test runner to run test on the primary appdomain and it solved the problem.
However, I recently decided to move debugger implementations to managed wrappers based on the MDBG sample code to support CLR 2.0 features and don't have any problems with this approach.
> I'm guessing you're using Managed C++ to write your debugger? Does
> your unit test harness create a new app-domain for running the tests?
>
> If that's the case, the KB article you mention could very well be your
> problem. I suspect the issue isn't specific to the fact that you're
> writing a debugger, but rather is an IJW/MC++ thing.
>
> If that's not the case, it might be helpful to include the message
> from the DllNotFoundException, as well as any information from
> fuslogvw.exe.
>
> Jonathan
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> --------------------
> | From: oleg stepanov <Oleg.Stepanov@jetbrains.com>
> | Subject: Debugger fails under unit test runner
> | Content-Type: text/plain; charset=koi8-ru
> | Message-ID: <#T8jgVbiEHA.3664@TK2MSFTNGP11.phx.gbl>
> | Newsgroups: microsoft.public.dotnet.framework.clr
> | Date: Tue, 24 Aug 2004 01:35:55 -0700
> | NNTP-Posting-Host: gw.intellij.net 195.5.138.42
> | Lines: 1
> | Path:
> cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSF
> TNGP11
> .phx.gbl
> | Xref: cpmsftngxa10.phx.gbl
> microsoft.public.dotnet.framework.clr:11685
> | X-Tomcat-NG: microsoft.public.dotnet.framework.clr
> |
> | Hi,
> |
> | I have a custom CLR debugger which uses standard CLR Debug API.
> Most of
> the time is works perfectly, but when it's run under unit test runner
> a
> DllNotFoundException is thrown. The problem seems to arise in
> CordbRCEventThread::FlushQueuedEvents when instance of IJWNOADThunk is
> created (see full stack below).
> | Does anyone have idea what might be the problem? I figured out
> that
> there's article in MSDN KB that DllNotFoundException might be raised
> when a
> native-to-managed call is performed in created app domain
> (
http://support.microsoft.com/default.aspx?scid=kb;EN-US;837318) - I
> wonder
> if it is related to my issue.
> | Thanks in advance for any help.
> |
> | The callstack:
> | [***SKIPPED***]
> | 083dfd24 792ae4c8 mscorwks!RealCOMPlusThrowHR+0x27, calling
> mscorwks!RealCOMPlusThrowHR
> | 083dfd38 792b1f70 mscorwks!IJWNOADThunk::NoModule+0xa, calling
> mscorwks!RealCOMPlusThrowHR
> | 083dfd40 7924d312 mscorwks!IJWNOADThunk::IJWNOADThunk, calling
> mscorwks!IJWNOADThunk::SafeNoModule
> | 083dfd44 7912022c
> mscordbi!CordbRCEventThread::FlushQueuedEvents+0x45
> | 083dfd64 791202f6 mscordbi!CordbRCEventThread::HandleRCEvent+0x73,
> calling mscordbi!CordbRCEventThread::FlushQueuedEvents
> | 083dfd7c 791204a9 mscordbi!CordbRCEventThread::ThreadProc+0x12a,
> calling
> mscordbi!CordbRCEventThread::HandleRCEvent
> | 083dfd8c 77f944a8 ntdll!RtlRemoteCall+0x1be, calling
> ntdll!wcstombs+0xa6
> | 083dfdc8 77f944a8 ntdll!RtlRemoteCall+0x1be, calling
> ntdll!wcstombs+0xa6
> | 083dffac 79120651 mscordbi!CordbRCEventThread::ThreadProc+0xb,
> calling
> mscordbi!CordbRCEventThread::ThreadProc
> | 083dffb4 77e7d33b KERNEL32!RegisterWaitForInputIdle+0x43
> | 083dffbc 77f944a8 ntdll!RtlRemoteCall+0x1be, calling
> ntdll!wcstombs+0xa6
> |
> | --
> | Oleg Stepanov
> | Software Developer
> | JetBrains, Inc
> |
http://www.jetbrains.com > | "Develop with pleasure!"
> |