Virtualbox error windows 10

I'd be interested to know if the message is thrown due to the presence of the hmpalert.dll being present in the Virtual box process(es).

If you open Process Explorer on this computer and take a look at the loaded modules you will see that 32-bit processes on a 64-bit computer load:

C:\windows\syswow64\hmpalert.dll

64-bit process on a 64-bit computer (or 32 on 32-bit) load:

C:\windows\sytem32\hmpalert.dll

Depending on the process, if it's 32-bit or 64 bit, if you rename the above dll(s) and relaunch the application is it fine?

If it still fails, without the actually loading of the hmpalert DLL, then I imagine it must be the driver (hmpalert.sys) injected shell code (that loads the DLL) into the process that is the issue.  To prove that you can rename the files back, then in the registry (hklm\system\currentcontrolset\hmpalert\) set start to 4 (remember the current value) then restart the computer.

With the hmplaert driver not starting, I assume the issue goes away?  This distinction between the two would be helpful.

You can set the start value back to the previous value to restore the driver loading on next startup.

Regards,

Jak 

I'd be interested to know if the message is thrown due to the presence of the hmpalert.dll being present in the Virtual box process(es).

If you open Process Explorer on this computer and take a look at the loaded modules you will see that 32-bit processes on a 64-bit computer load:

C:\windows\syswow64\hmpalert.dll

64-bit process on a 64-bit computer (or 32 on 32-bit) load:

C:\windows\sytem32\hmpalert.dll

Depending on the process, if it's 32-bit or 64 bit, if you rename the above dll(s) and relaunch the application is it fine?

If it still fails, without the actually loading of the hmpalert DLL, then I imagine it must be the driver (hmpalert.sys) injected shell code (that loads the DLL) into the process that is the issue.  To prove that you can rename the files back, then in the registry (hklm\system\currentcontrolset\hmpalert\) set start to 4 (remember the current value) then restart the computer.

With the hmplaert driver not starting, I assume the issue goes away?  This distinction between the two would be helpful.

You can set the start value back to the previous value to restore the driver loading on next startup.

Regards,

Jak 

Hello good afternoon
Thank you very much for your reply.
Rename the hmpalert.sys file and re-run the program and the problem even Persians.
In the path "hklm \ system \ currentcontrolset \" The registry "hmpalert"
I thank you if you can pass another test and we gladly do it.

thank you very much

regards

Leonel

Hola buenas tardes
Muchas gracias por su respuesta.
Renombramos el archivo hmpalert.sys y se volvio a ejecutar el programa y el problema aun persas.
En la ruta "hklm \ system \ currentcontrolset \" No se encontró el registro "hmpalert"
Le agradezco si puede pasarno otra prueba y con gusto la realizamos.

muchas gracias

Saludos

Leonel

Renaming the driver file (hmplaert.sys) wouldn't have any effect until the computer was restarted.  At which point the driver wouldn't be loaded, this would be the same as setting:

hklm \ system \ currentcontrolset \ services \ hmpalert 

Start to 4 (disabled)

and rebooting.

Did you also run the tests or renaming the hmplaert.dll files in:
\windows\system32\

and 

\windows\syswow64\

I would be interested to know if the issue is with the driver (hmpalert.sys) or the module (hmplaert.dll)

Regards,

Jak

Good afternoon.

We did the requested steps, but the problem still persists.

Read thank you if you can give us any possible solution.

thank you very much.

regards

Leonel

Estimados buenas tardes.
Realizamos los pasos solicitados, pero aun el problema persiste.

Lea agradezco si puede brindarnos alguna solucion posible.

muchas gracias.

saludos

Leonel

OK, so you have confirmed that hmpalert.dll is no longer being loaded into processes and the hmplaert.sys driver is no longer being loaded into the System process.  

I would suggest using Process Explorer to confirm this.

I would then focus on the other modules loading into the Virtual box processes.  

The next obvious one is the Sophos detours module as loaded by from the AppInit_Dlls key(s):

https://msdn.microsoft.com/library/windows/desktop/dd744762(v=vs.85).aspx

https://support.microsoft.com/help/197571/working-with-the-appinit-dlls-registry-value

To disable this from both 32 and 64-bit process as a test to eliminate it, setting:

LoadAppInit_DLLs to 0 under:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

and

HKEY_LOCAL_MACHINE\SOFTWARE\wow6432node\Microsoft\Windows NT\CurrentVersion\Windows

Note: this will prevent all DLLs listed in the AppInit_DLLs value from loading as well which you may have others.

You will then need to re-luaunch/restart services for the module to not be loaded on the next start.  Again Process Explorer can confirm if this module is being loaded.

Regards,

Jak

Dear Jak, good day.
That's right, doing this virtualbox procedure worked correctly.
Is there any solution to this problem? Can you leave this dll disabled?

Thank you very much.

regards

Leonel

Estimado Jak buen dia.
Es correcto, realizar este procedimiento virtualbox funciono correctamente.
¿Hay alguna solución para este problema? Se puede dejar esta dll deshabilitada ?.

Muchas gracias.

Saludos

Leonel

I think it would be more of a question for support to dig deeper if needed.  I've a feeling that could take serious debugging with code and symbols if they can reproduce it.

You can set:

64-bit computers:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Sophos\SAVService\SetupOptions]
"DetourDLLState"="excluded"

32-bit computers:
[HKEY_LOCAL_MACHINE\SOFTWARE\Sophos\SAVService\SetupOptions]
"DetourDLLState"="excluded"

This will ensure that Sophos detours is never installed on update.  I would suggest this as the "fix" rather than setting LoadAppInit_DLLs to 0.  

I would:

• Remove the Sophos DLL paths from both the AppInit_DLLs values.
• Set LoadAppInit_DLLs back to 1
• Set the above "excluded" registry values to prevent re-install.

Sophos Data Control uses detours but if you're not using that it you're not loosing any functionality there.

It does provide buffer overflow technology for the processes loaded into but to be fair, I believe the mitigation functionality of InterceptX and coupled with a later OS, you're not missing out without it.

Regards,

Jak