Opened 22 months ago
Last modified 21 months ago
#21303 new defect
exception in module VBoxMRXNP.dll => Fixed in SVN
| Reported by: | medved | Owned by: | |
|---|---|---|---|
| Component: | shared folders | Version: | VirtualBox-7.0.4 |
| Keywords: | Cc: | ||
| Guest type: | Windows | Host type: | Windows |
Description
application running in MS Visual Studio 2019 crashes if it tries to access the file system (retrieve folder structure). In VirtualBox 6.1 it works fine.
windows Event log: Faulting application name: EstiCon.Client.exe, version: 22.3.4.100, time stamp: 0x637e116c Faulting module name: VBoxMRXNP.dll, version: 7.0.4.4605, time stamp: 0x6375102d Exception code: 0x4000001f Fault offset: 0x000132b0 Faulting process id: 0x448c Faulting application start time: 0x01d8ff37dd906849 Faulting application path: c:\projekty\EstDevTest\Client\EstiCon.Client\bin\Debug\EstiCon.Client.exe Faulting module path: C:\WINDOWS\system32\VBoxMRXNP.dll Report Id: 7eb1303a-fddb-4eb3-a7ef-848370c48846 Faulting package full name: Faulting package-relative application ID:
Attachments (1)
Change History (6)
by , 22 months ago
| Attachment: | w10develop-2022-11-23-13-50-43.log added |
|---|
comment:2 by , 22 months ago
The same happens to me with Visual Studio 2017 on Windows 10 after upgrading to VirtualBox 7.0.4
comment:3 by , 21 months ago
(may help) - found an old stacktrace on error 0x4000001f:
https://stackoverflow.com/questions/42413553/net-application-exits-without-exception-0x4000001f
and also:
https://stackoverflow.com/questions/4532457/program-and-debugger-quit-without-indication-of-problem
comment:4 by , 21 months ago
Reproduced this issue locally and what I could find out so far is that it really only happens when a debugger is present and the application is executed as a x86 (32-bit) application under SysWOW64. If you set the target as x64 in Visual Studio you should be able to avoid this particular crash. Investigating a fix currently.
comment:5 by , 21 months ago
| Summary: | exception in module VBoxMRXNP.dll → exception in module VBoxMRXNP.dll => Fixed in SVN |
|---|
Sorry, this was due to the 32-bit CRT replacement code missing some structured exception handling code (_except_handler4). When a debugger is detected, we raise a special exception to inform it about the name of a thread, if the debugger doesn't deal properly with this exception, the we're ignoring it via a __try/__except construct. Due to time pressure only the 64-bit support code for that SEH construct had been implemented, so 32-bit processes would misbehave if a back level debugger is used.
Just committed a basic _except_handle4 implementation and a testcase covering the debugger scenario. I haven't had time to test the actual scenario mentioned here in the ticket, but it should be fixed as well. The next VBox release will include the fix (or a test build with revision 154949 or higher).


I'm having a similar behavior in VS 2022 17.4. with VBox 7.0.2/7.0.4 (same faulting module name + Version, exception code, and fault offset)
It's quite simple to reproduce:
While debugging, it will crash the programm and terminate the debugger on ShowDialog(). Error code on exit is 0x4000001f as above. However, running the compiled code works fine.
By accident I had a machine with Guest Additions 6.0.14r133895 installed on 7.0.2. That _did_ work. Only after i upgraded the Guest Additions to 7.0.2 / 7.0.4 it crashed.
BTW I'm not sure, if should create a new ticket ???