VirtualBox

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)

w10develop-2022-11-23-13-50-43.log (124.8 KB ) - added by medved 22 months ago.

Download all attachments as: .zip

Change History (6)

comment:1 by VisAlf, 22 months ago

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:

  • Create an empty form in VS (wpf or winforms, i used net 6, C#),
  • add a button,
  • on click, call
      var dlg = new FolderBrowserDialog();
      dlg.ShowDialog();
    
    

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 ???

Last edited 22 months ago by VisAlf (previous) (diff)

comment:2 by Vittorio, 22 months ago

The same happens to me with Visual Studio 2017 on Windows 10 after upgrading to VirtualBox 7.0.4

comment:4 by aeichner, 22 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.

Last edited 22 months ago by aeichner (previous) (diff)

comment:5 by bird, 21 months ago

Summary: exception in module VBoxMRXNP.dllexception 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).

Note: See TracTickets for help on using tickets.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette