Microsoft MVP성태의 닷넷 이야기
How to get a V2.0 ICorDebug object [링크 복사], [링크+제목 복사],
조회: 9354
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

[출처] https://docs.microsoft.com/en-us/archive/blogs/jmstall/how-to-get-a-v2-0-icordebug-object

결국 "온고지신"이라는 말이 떠오릅니다.
COM과 Win32 API는 보이지만 않게 될 뿐, 여전히 하부에서 존재하고 있습니다.


How to get a V2.0 ICorDebug object

I think the biggest breaking change in the ICorDebug API is how we deal with versioning.

Managed debugging is done via the com-classic ICorDebug interface.

 

In v1.0/v1.1, you cocreate to get an ICorDebug implementation, like so:

 

        ICorDebug * cor;

        hr = CoCreateInstance(CLSID_CorDebug, NULL,

                              CLSCTX_INPROC_SERVER,

                              IID_ICorDebug,

                              (void **)&cor);

 

This has a few problems:

-         COM activation is evil because it means a more complex setup to update the registry. This allows bugs like “you need to reregister mscordbi.dll”. A quick google search shows that people hit this problem enough.

-         there are no version parameters in here

 

In v2.0, there is no longer a com coclass for ICorDebug. We still use the com-class ICorDebug interfaces, but we don’t use COM activation anymore. You now call a new API defined in mscoree.idl:

STDAPI CreateDebuggingInterfaceFromVersion(

int iDebuggerVersion,

LPCWSTR szDebuggeeVersion,

IUnknown ** ppCordb);

 

This takes version parameters. iDebuggerVersion is a constant from CorDebug.idl specifying the version of the API the client is built against.  szDebuggeeVersion is the version string of the debuggee. 

*ppCordb is an out parameter for the newly allocated com-object.

 

Here’s some sample code to use the new API:

 

    // Sample code to get an ICorDebug instance to debug v1.1.

    typedef HRESULT (STDAPICALLTYPE *FPCreateCordb)(int iDebuggerVersion, LPCWSTR szDebuggeeVersion, IUnknown ** ppCordb);

 

    // Must late bind to CreateDebuggingInterfaceFromVersion since it may not be installed.

    HMODULE hMscoree = LoadLibraryA("mscoree.dll");

    if (hMscoree == null) { /* Serious error, v2.0 runtime is not installed! */ }

    FPCreateCordb fpCreateCordb = (FPCreateCordb) GetProcAddress(m_hMscoree, "CreateDebuggingInterfaceFromVersion");

    if (fpCreateCordb == NULL) {  /* fail */ }

 

    const char * szDebuggeeVersion = “v1.1.4322”; // if we’re debugging a v1.1 debuggee

    const int iDebuggerVersion = CorDebugVersion_2_0; // if we’re a v2.0 debugger.

    hr = fpCreateCordb(CorDebugVersion_2_0, szEverettVersion, &pObject);

    if (FAILED(hr)) { /* fail */ }

 

    ICorDebug * cor;

    hr = pObject->QueryInterface(IID_ICorDebug, (void**) &cor);

    if (FAILED(hr)) { /* fail */ }

 

Note that MDbg in the beta 1 sample is still using the old API, but we’ve updated it in the beta2 release.

 

Why the change?

The debugging services in V1 didn’t have a good versioning plan. The original idea was that the debugger would just create a single instance of ICorDebug (via CoCreate) and that would emulate all other versions as needed.

This was a bad idea.

That means if you have an v1 debugger on a v1 debuggee, you’ll use the v1 implementation of ICorDebug. As soon as you install a v2 CLR, that scenario is automatically updated to use a V2 implementation of ICorDebug.

If that new implementation doesn’t perfectly emulate the old one, then the mere act of installing a new v2 runtime would have broken a pure v1 scenario.

The test matrix also explodes very quickly. We’d have to test every version against every previous version.

 

ICorDebug design flaws also prevent us from shimming implementations underneath the interface either. We don’t know the version of the debuggee until a CreateProcess callback is dispatched, but there’s still a lot of functionality before that callback (including interop-debugging support).

 

We concluded the only viable alternative was to keep 1 version of the ICorDebug implementation  per CLR. With the new APIs, installing a new CLR does not have any impact on the what happens to the debugging pipeline of existing apps. You’ll also notice now that the version of mscordbi.dll in the debugger will always strictly match the version of mscorwks.dll in the debuggee. So when a v2.0 debugger is debugging a v1.0 application, it loads the v1.0 mscordbi. (Unfortunately, this will be a problem for debuggers implemented in managed code. See here for details.).

 

This ugliness is an example of the consequence of not really thinking about versioning until v2.0.

 

Issues with the new design:

The biggest immediate problem with the new design is where do you get the debuggee’s version string from? The debugger needs to predict the debuggee’s version before it launches it. There are a few APIs in mscoree.idl to help with this:

1)      GetCORVersion   this will get the version string for the currently executing process. This works fine if the debugger + debuggee have the same version. (This is what beta 1 MDbg does.)

2)      GetRequestedRuntimeVersion   this predict the version string from an executable on disk based off policy settings, config files, etc. This will always be accurate for a pure-managed app like C#.

3)      GetVersionFromProcess   this will find the version string from a currently running process. This API was added in v2.0 to explicitly support this scenario.

 

There are of course cases where there’s no way to predict the version string. Consider a pure native app that pops up a dialog box asking the user which runtime to bind to and then calls CorBindToRuntimeEx on the fly.

 

All this said, we considered these limitations doable given the scenarios we wanted to support.

 

Published Saturday, January 15, 2005 5:02 PM by jmstall
Filed Under: ,






[최초 등록일: ]
[최종 수정일: 6/16/2021]


비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  [37]  38  39  40  41  42  43  44  45  ...
NoWriterDateCnt.TitleFile(s)
269정성태5/4/20069032Visual Studio 2005 Team System Level 200 Course Material
268정성태5/4/20069312Microsoft Component Installer Software Development Kit for Windows (x86) Version 2.0
267정성태5/4/20069208101 Code Samples for Visual Basic 2005
266정성태5/3/200611023Consolas Font Pack for Microsoft Visual Studio 2006 [2]
264정성태5/1/200610209Team System for C++ Developers
262정성태5/1/200619777Registry 등록 없이 COM 개체 사용 [1]파일 다운로드2
261정성태4/30/2006100484GB 메모리 인식 [2]
259정성태4/30/20069113Building ASP.NET 2.0 Web Sites Using Web Standards
260정성태4/30/20068815    답변글 XHTML Validator Modulle
258정성태4/29/20069395WebServiceStudio 2.0
263정성태5/1/20069037    답변글 Calling an Arbitrary Web Service
257정성태4/29/20069004TypeForwardedToAttribute
256정성태4/29/20069262Windows API - Using Condition Variables
252정성태4/26/20069477한글 관련 메세지 정리파일 다운로드1
251정성태4/26/20069933IIS 7.0 에서 소개되는 새로운 기능들 [1]
250정성태4/25/200610637툴 소개: VisualNDepend
249정성태4/25/200616629Integrating a debugger into Reflector
265정성태5/1/200610881    답변글 Deblector: First Version
285정성태5/15/20068985    답변글 New Deblector version ( an Add-In to debug with reflector )
248정성태4/21/20069344VS.NET 2005 Add-In : CSS Properties Window
247정성태4/21/20069266VS.NET 2005 Add-In : Spell Checker for HTML and ASP.NET pages
244정성태4/19/20069218SQL Server 2005 Service Pack 1
241정성태4/19/20068682VSTS Annotations for C++: Beyond Just Documenting Method Behavior [1]파일 다운로드1
240정성태4/18/20069320Accessing System Power and Network Status Using SENS
253정성태4/29/20069658    답변글 [HowToUse]: Accessing System Power and Network Status Using SENS
239정성태4/18/20069240Display a Web Page in a Plain C Win32 Application
... 31  32  33  34  35  36  [37]  38  39  40  41  42  43  44  45  ...