NtWriteVirtualMemory failed writing child process parameters

[jroselarsen]

This is now happening on ALL my VM's with VirtualBox (5.0.30) when hitting Start.

NtWriteVirtualMemory.jpg (48 KiB) Viewed 4405 times

I haven't been using VB for some months, so there has been several Windows updates since.
Vindows 7, SP1, latest updates.
AV is AVG Internet Security. Has been working with this previously.
Any ideas where to look ???
BR Johnny

VboxHardening.log:
[Mod edit: Removed partial VBoxHardening.log]

[socratis]

Partial logs are not that helpful I'm afraid. Please ZIP and attach the full log. See the "Upload attachment" tab below the reply form.

[jroselarsen]

Sorry, didn't notice it ended up partial. File attached.

[mpack]

I'd guess that your AVG antivirus software is conflicting with VirtualBox.

[jroselarsen]

This is strange, because it has worked previously.
I've tried to disable AVG, and the problem persists.
From the log it seems that VB has passed checking the drivers and is starting the VM, but can't write to it's memory.
Nothing in AVG logs points at any error either and Virtualbox has been added to exceptions.
Wonder if Microsoft has hardened anything recently?
Error code 0xc00000005 is 'access violation'.
VB is running with administrator priviledge.

I have VMWare WS12 as well, and it works perfectly......
Never run simultaniously.
Reboot and re-installation of VB has been tried.

Any other ideas ??

[mpack]

Error code 0xc00000005 is 'access violation'.

The hardening related access violation usually means that a DLL got ejected because it wasn't signed - other parts of whatever app (something invasive, that wants to run inside the VirtualBox program space) wanted that DLL crash when they try to call it.

So, you have an invasive app, non-native or all all users of that Windows version would see it, and the invasive app can't be hugely widespread for the same reason. Most often it's antivirus or graphics drivers, the latter applicable only if you have 3D acceleration enabled.

I have VMWare WS12 as well, and it works perfectly......

I can't imagine what possible relevance you thought that would have. We aren't trying to find a conflict with VMWare, and I have no idea what hardening checks (if any) VMWare does anyway.

[socratis]

This is strange, because it has worked previously.

Things usually work until they break

I've tried to disable AVG, and the problem persists.

I'm afraid that's not enough. You need to uninstall it, since it loads kernel drivers at system startup. Disabling the front end does not disable the loaded components or the engine.

From the log it seems that VB has passed checking the drivers and is starting the VM, but can't write to it's memory.

The log is incomplete. I don't know where you saw those things that your refer to. Did you grab the log before the process ended?

Nothing in AVG logs points at any error either and Virtualbox has been added to exceptions.

AVG won't show you errors, VirtualBox will. That doesn't change the fact that AVG will load itself with any process.

Wonder if Microsoft has hardened anything recently?

Could be? When was the last update?

Error code 0xc0000005 is 'access violation'.

Yes, due to hardened security.

VB is running with administrator priviledge.

Not a good idea. You should run it as "you". No "Run as Administrator", nor logging as Administrator. Unless you are the Administrator, but still the "Run as Administrator" is a no-go.

I have VMWare WS12 as well, and it works perfectly......

Not related to this discussion I'm afraid. I bet that Notepad or SolidWork runs fine as well.

[jroselarsen]

Got your points.
I was assuming dll checks were finished due to this in the end of the log:
1908.c84: supR3HardNtEnableThreadCreation:
1908.c84: supR3HardNtDisableThreadCreation: pvLdrInitThunk=0000000076d2a360 pvNtTerminateThread=0000000076d4c260
1908.c84: supR3HardenedWinDoReSpawn(1): New child 2394.1cd0 [kernel32].
1908.c84: supR3HardNtChildGatherData: PebBaseAddress=000007fffffdd000 cbPeb=0x380
1908.c84: supR3HardNtPuChFindNtdll: uNtDllParentAddr=0000000076d00000 uNtDllChildAddr=0000000076d00000
1908.c84: Error (rc=-1073741819):
1908.c84: NtWriteVirtualMemory(,000000013f6a9960,) failed writing child process parameters: 0xc0000005


I'll try to investigate further into updates and AVG.

[mpack]

Admittedly it's an unusual form of the error message. It kind of implies that it was VirtualBox which tried to interact with a child process (the invasive app) but failed, because the app was not present. That suggests that the app may have only been present briefly.

I'm still thinking AVG.

[jroselarsen]

Found the code on Github.
Does not seem like an error is expected at this time: (will further check on AVG).

Code: Select all

/**
 * Sets up the early process init.
 *
 * @param   pThis               The child process data structure.
 */
static void supR3HardNtChildSetUpChildInit(PSUPR3HARDNTCHILD pThis)
{
    uintptr_t const uChildExeAddr = (uintptr_t)pThis->Peb.ImageBaseAddress;

    /*
     * Plant the process parameters.  This ASSUMES the handle inheritance is
     * performed when creating the child process.
     */
    RT_ZERO(pThis->ProcParams);
    pThis->ProcParams.hEvtChild  = pThis->hEvtChild;
    pThis->ProcParams.hEvtParent = pThis->hEvtParent;
    pThis->ProcParams.uNtDllAddr = pThis->uNtDllAddr;
    pThis->ProcParams.enmRequest = kSupR3WinChildReq_Error;
    pThis->ProcParams.rc         = VINF_SUCCESS;

    uintptr_t uChildAddr = uChildExeAddr + ((uintptr_t)&g_ProcParams - (uintptr_t)NtCurrentPeb()->ImageBaseAddress);
    SIZE_T    cbIgnored;
    NTSTATUS  rcNt = NtWriteVirtualMemory(pThis->hProcess, (PVOID)uChildAddr, &pThis->ProcParams,
                                          sizeof(pThis->ProcParams), &cbIgnored);
    if (!NT_SUCCESS(rcNt))
        supR3HardenedWinKillChild(pThis, "supR3HardenedWinSetupChildInit", rcNt,
                                  "NtWriteVirtualMemory(,%p,) failed writing child process parameters: %#x\n", uChildAddr, rcNt);

[socratis]

Found the code on Github.

Interesting, I didn't know it was mirrored in GitHub. You can also find the snippet in the official source code in "vbox/trunk/src/VBox/HostDrivers/Support/win/SUPR3HardenedMain-win.cpp", function "supR3HardNtChildSetUpChildInit", around line 3570 (as of this writing).

[jroselarsen]

To add to the puzzle:
I just installed latest VB on another machine also using AVG.
Installed one of the machines from my other installation (new - using disk image already set-up) and it runs like a charm.

This PC has not been updated through MS for a while, so I'll persue that direction - at least for now.
BR Johnny

[jroselarsen]

Problem solved.
Caused by AVG Software which activates ifself as debugger for, in this case, virtualbox.exe. This happens when the program is started.
This is done in the registry through the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Removing virtualbox.exe did it.

[mpack]

Well done for finding it.

[socratis]

Nice detective work!
But it also begs me to ask a question. Not to be necessarily answered, but more to have it in the back of our heads. I didn't quite like the sound of the following:

Caused by AVG Software which activates ifself as debugger for, in this case, virtualbox.exe.

Debuggers these days have been known to use VT-x. I'm not sure if AVG is doing it, and if it is working in a "cooperative multitasking", "VT-x sharing" kind of a way. But it's something to keep in mind...