winafl.dll instrumentation crashes with access violation when running drrun.exe

I'm trying to fuzz a target DLL for which I built an harness for (both 64bit).

if I run drrun.exe without winafl.dllinstrumentation, it works: drrun.exe -c bbcount.dll -- target.exe

If I execute drrun.exe with winafl.dll instead:

drrun.exe -c winafl.dll -debug -- target.exe

The target immediately crashes. logfile below:

Module loaded, dynamorio.dll
Module loaded, winafl.dll
Module loaded, drx.dll
Module loaded, drreg.dll
Module loaded, drmgr.dll
Module loaded, drwrap.dll
Module loaded, target.exe
Module loaded, ucrtbased.dll
Module loaded, MSVCP140D.dll
Module loaded, VCRUNTIME140_1D.dll
Module loaded, VCRUNTIME140D.dll
Module loaded, KERNELBASE.dll
Module loaded, KERNEL32.dll
Module loaded, ntdll.dll
Module loaded, ucrtbase.dll
Module loaded, VCRUNTIME140.dll
Module loaded, VCRUNTIME140_1.dll
Module loaded, MSVCP140.dll
Module loaded, msvcp_win.dll
Module loaded, gdi32full.dll
Module loaded, GDI32.dll
Module loaded, USER32.dll
Module loaded, IMM32.dll
Module loaded, win32u.dll
Module loaded, MPR.dll
Module loaded, IPHLPAPI.DLL
Module loaded, RPCRT4.dll
Module loaded, combase.dll
Module loaded, ole32.dll
Module loaded, SHELL32.dll
Exception caught: c0000005
crashed
WARNING: Target function was never called. Incorrect target_offset?
Coverage map follows:

I attached with WinDBG to my harness process after it was spawned by drrun.exe and it was crashing when my harness called LoadLibraryW to load the target DLL. Here it's a piece of code from my harness:

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow) {
    printf("main started, waiting for debugger....\n");
    Sleep(10000);

    HMODULE hImporter = NULL;

    hImporter = LoadLibraryW(L"target.dll");

This is the call stack in WinDBG (ImporterSDK is my harness):

If I continue the execution, it crashes (Access Violation) at the following instruction:

I don't know where this code is actually located, since the call stack is not giving any clues. I guess it has to be some winafl instrumentation code that hooked the call to LoadLibrary?

Usually, is not fs:[0C0h] used for 32bit binaries? I compiled everything as 64bit. If I load another library, as for example KERNEL32, instead of the target library I want to fuzz, the LoadLibraryW call is executed correctly also with the winafl.dll instrumentation.

googleprojectzero / winafl

winafl.dll instrumentation crashes with access violation when running drrun.exe #381