Как вы сопоставляете собственный указатель инструкций с IL в процессе

Чтобы преобразовать собственный указатель инструкций, предоставленный ICorProfilerInfo2::DoStackSnapshot, в смещение метода промежуточного языка, вы должны выполнить два шага, поскольку DoStackSnapshot предоставляет FunctionID и собственный указатель инструкций в качестве адреса виртуальной памяти.

Шаг 1 заключается в преобразовании указателя инструкции в смещение метода собственного кода. (смещение от начала JIT-метода). Это можно сделать с помощью ICorProfilerInfo2::GetCodeInfo2

ULONG32 pcIL(0xffffffff);
HRESULT hr(E_FAIL);
COR_PRF_CODE_INFO* codeInfo(NULL);
COR_DEBUG_IL_TO_NATIVE_MAP* map(NULL);
ULONG32 cItem(0);

UINT_PTR nativePCOffset(0xffffffff);
if (SUCCEEDED(hr = pInfo->GetCodeInfo2(functioId, 0, &cItem, NULL)) &&
    (NULL != (codeInfo = new COR_PRF_CODE_INFO[cItem])))
{
    if (SUCCEEDED(hr = pInfo->GetCodeInfo2(functionId, cItem, &cItem, codeInfo)))
    {
        COR_PRF_CODE_INFO *pCur(codeInfo), *pEnd(codeInfo + cItem);
        nativePCOffset = 0;
        for (; pCur < pEnd; pCur++)
        {
            // 'ip' is the UINT_PTR passed to the StackSnapshotCallback as named in
            // the docs I am looking at 
            if ((ip >= pCur->startAddress) && (ip < (pCur->startAddress + pCur->size)))
            {
                nativePCOffset += (instructionPtr - pCur->startAddress);
                break;
            }
            else
            {
                nativePCOffset += pCur->size;
            }

        }
    }
    delete[] codeInfo; codeInfo = NULL;
}

Шаг 2. Получив смещение от начала метода нативного кода, вы можете использовать его для преобразования в смещение от начала метода промежуточного языка с помощью ICorProfilerInfo2::GetILToNativeMapping.

if ((nativePCOffset != -1) &&
    SUCCEEDED(hr = pInfo->GetILToNativeMapping(functionId, 0, &cItem, NULL)) &&
    (NULL != (map = new COR_DEBUG_IL_TO_NATIVE_MAP[cItem])))
{
    if (SUCCEEDED(pInfo->GetILToNativeMapping(functionId, cItem, &cItem, map)))
    {
        COR_DEBUG_IL_TO_NATIVE_MAP* mapCurrent = map + (cItem - 1);
        for (;mapCurrent >= map; mapCurrent--)
        {
            if ((mapCurrent->nativeStartOffset <= nativePCOffset) && 
                (mapCurrent->nativeEndOffset > nativePCOffset))
            {
                pcIL = mapCurrent->ilOffset;
                break;
            }
        }
    }
    delete[] map; map = NULL;
}

Затем это можно использовать для сопоставления местоположения кода с файлом и номером строки с помощью API-интерфейсов символов.

Благодаря Митхуну Шанбхагу за направление в поиске решения.

Console.WriteLine("StackTrace: '{0}'", Environment.StackTrace);

Убедитесь, что ваша сборка генерирует символы.

Расширение обсуждения:

Как, вероятно, очевидно, я делаю снимок текущего стека и хотел бы предоставить информацию о номере файла и строке в дампе стека.

Учитывая это. Похоже, единственная причина, по которой вы не подключаетесь к процессу, заключается в том, что вы можете легко отлаживать свой инструмент или его части во время его разработки. Эта ИМО является плохим оправданием для того, чтобы не выбрать лучший дизайн (ICorDebug или w/e), когда он доступен. Причина его плохого дизайна заключается в том, что ваш код выполняется в пространстве процессов (предположительно) внешних двоичных файлов, вызывая неприятные («иногда» редкие) побочные эффекты (включая повреждение чужих данных) в известных (или, что еще хуже, неизвестных) поврежденных состояниях процесса. Этого должно быть достаточно для начала, но даже в противном случае есть несколько крайних случаев с многопоточным кодом и т. д., где дизайн необходимо обойти.

Большинство людей обычно спрашивают: «Что вы на самом деле пытаетесь сделать?» как ответ на откровенно сложный способ ведения дел. В большинстве случаев есть более простой способ. Написав трассировщик стека для нативного кода, я знаю, что он может запутаться.

Теперь, может быть, вы в конечном итоге заставите все работать, так что - Просто мои 0,02 доллара.