Fix minidump generation when there is a NDirect method in the stack

[thaystg]

Only get the il from PE if it's not nDirect Method because the IL of a NDirect is dynamically generated so it does not make sense to get it from the PE.

[Copilot]

Pull Request Overview

This PR aims to fix minidump generation by avoiding retrieval of IL from the PE for NDirect methods, since their IL is dynamically generated.

• Added an extra check (!IsNDirect()) before attempting to retrieve the IL header.
• Ensures that the IL header is only fetched for non-NDirect methods.

Comments suppressed due to low confidence (1)

src/coreclr/vm/method.cpp:1211

• [nitpick] Consider adding a brief comment explaining that NDirect methods generate dynamic IL and therefore do not require IL header retrieval from the PE. This could enhance code clarity for future maintainers.

if (pIL == (TADDR)NULL && !IsNDirect())

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[jkotas]

Only get the il from PE if it's not nDirect Method because the IL of a NDirect is dynamically generated so it does not make sense to get it from the PE.

Could you please share stacktrace for the crash that this is fixing?

I do not see the problem with the current code. GetRVA should return 0 for (NDirect) P/Invoke methods. Module::GetIL has early our for RVA == 0.

If there is a problem with this path, there are likely more types of methods that we need to check here (e.g. FCalls, etc.).

[jkotas]

Notice that this method has a PRECONDITION(IsIL()). It means that it is not expected to be called on IsNDirect method in the first place.

I think the correct fix is to add if (IsIL()) check around the whole CodeVersionManager related block in MethodDesc::EnumMemoryRegions.

[jkotas]

GetRVA should return 0 for (NDirect) P/Invoke methods. Module::GetIL has early our for RVA == 0.

One possible explanation is that this is IJW module (are you able to confirm it with the customer?) and GetRVA returns the address of native code in that case. We try to interpret the native code as IL and crash.

[tommcdon]

Could you please share stacktrace for the crash that this is fixing?

mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!DacError(HRESULT err) Line 102
mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!DacInstantiateTypeByAddressHelper(unsigned __int64 addr, unsigned int size, bool t...
[Inlined Frame] mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!DacInstantiateTypeByAddress(unsigned __int64 addr) Line 449
[Inlined Frame] mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!_DPtr<tag<COR_ILMETHOD_SECT_SMALL>::operator->() Line 1202
mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!PEDecoder::ComputeILMethodSize(unsigned __int64 pIL) Line 2303
[Inlined Frame] mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!DacGetIlMethod(unsigned __int64) Line 1325
mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!MethodDesc::GetILHeader(int fAllowOverwrites) Line 1100
mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!ILCodeVersion::GetIL() Line 923
mscordaccore_AMD64_AMD64.8.0.1224.60305.dll!MethodDesc::EnumMemoryRegions(CLRDataEnumMemoryFlags flags) Line 3799

One possible explanation is that this is IJW module (are you able to confirm it with the customer?) and GetRVA returns the address of native code in that case. We try to interpret the native code as IL and crash.

Confirmed that it is an IJW app