Description

While playing with WER, I noticed that the .NET Core WER handler (in the DAC) was not taking ownership of the crashes (in OutOfProcessExceptionEventCallback), and therefore not setting the Watson buckets.

After some debugging, I narrowed it down to WasThrownByUs returning false, and more specifically this check:

if ((ULONG_PTR)GetClrModuleBase() != pcER->ExceptionInformation[INSTANCE_TAGGED_SEH_PARAM_ARRAY_SIZE - 1] )

The information in pcER->ExceptionInformation[INSTANCE_TAGGED_SEH_PARAM_ARRAY_SIZE - 1] is correct, and contains the address of coreclr.dll in the crashing process. However, GetClrModuleBase() returns the address of the DAC in WerFault.exe, and therefore the two values don't match.

I believe the regression was introduced by #43735. Before that change, this part of the code used GetCLRModule() which returned g_hmodCoreCLR. When initializing the DAC, the value of g_hmodCoreCLR was set to the address of coreclr.dll in the target process, thus making the check correct.

Note that IsExceptionFromManagedCode also has a second check that returns false: ExecutionManager::IsManagedCode((PCODE)address). I haven't tried to understand if it's expected or not.

Honestly I don't know if anybody cares about this feature at all, it just seemed weird to me to register a WER handler that is always failing.

Reproduction Steps

Write a simple application that crashes because of an unhandled exception:

    static void Main(string[] args)
    {
        throw new Exception("Crashing");
    }

Expected behavior

The WER handler in the DAC takes ownership of the crash.

Actual behavior

The WER handler in the DAC doesn't take ownership of the crash.

Regression?

This worked in .NET Framework.

Known Workarounds

No response

Configuration

No response

Other information

No response