VirtualBox

Opened 10 years ago

Last modified 4 years ago

#12646 reopened defect

XP Guest GPF in WIN87EM.DLL at 0001:02C9 or 0001:02C6 => Fixed in SVN

Reported by: SteveDeveloper Owned by:
Component: other Version: VirtualBox 4.3.4
Keywords: Cc:
Guest type: Windows Host type: Windows

Description

When running 16 bit Apps in XP, there is an occasional GPF in WIN87EM.DLL at 0001:02C9 or 0001:02C6. Same app sometimes works OK. For me, this problem did not exist through many version of VB through 4.2.18 and started with 4.3.4.

The only web research I have was from a VMWare post that may or may not apply here (quoted from cwsault original post):

"There are a few applications which may fail with this error when executed in a VM. The problem is that the library tries to read the instruction bytes of the last FPU instruction executed based on the code segment and instruction pointer saved in the FPU environment. Unfortunately, the code segment saved in the FPU environment may be NULL.

When we switch between the virtual machine monitor and the host operating system, we use the primitive hardware instructions to save and restore the FPU state. These instructions were not really designed for an environment that mixes 32-bit and 64-bit execution. When the instructions are executed in 64-bit mode, they don't keep track of the code segment, since segments have little meaning in 64-bit mode. The virtual machine monitor, which saves and restores the FPU state for the guest VM, executes in 64-bit mode. Hence, the FPU code segment is lost.

Fortunately, there is a workaround for this issue. If you add the following option to your configuration file, we will make sure that the FPU code segment is properly saved and restored when switching between the virtual machine monitor and the host operating system (at some small performance penalty): monitor_control.enable_rigorous_fpu_save_restore = TRUE"

Attachments (3)

LAST VM 4_2_18 XPHome-2013-11-28-11-56-27.log (88.3 KB ) - added by SteveDeveloper 10 years ago.
Last Log without any GPF problem
NEW VM 4_3_4 XPHome-2013-12-04-13-40-50.log (58.7 KB ) - added by SteveDeveloper 10 years ago.
First log when GPF issue started
TestVM-VBox.log (114.8 KB ) - added by ZendX 4 years ago.
vbox.log

Download all attachments as: .zip

Change History (14)

by SteveDeveloper, 10 years ago

Last Log without any GPF problem

by SteveDeveloper, 10 years ago

First log when GPF issue started

comment:1 by Ramshankar Venkataraman, 10 years ago

Summary: XP Guest GPF in WIN87EM.DLL at 0001:02C9 or 0001:02C6XP Guest GPF in WIN87EM.DLL at 0001:02C9 or 0001:02C6 => Fixed in SVN

Fix should be available as part of the next maintenance release of VirtualBox 4.3.x.

comment:2 by Frank Mehnert, 10 years ago

Resolution: fixed
Status: newclosed

Fix is part of VBox 4.3.16.

comment:3 by ZendX, 4 years ago

Resolution: fixed
Status: closedreopened

Host OS: Windows 10 x64
Host CPU: Intel Core I7-7500U
Guest OS: Windows XP 32-bit
Virtualbox Version: 6.1.4 r136177

Problem still persists.
16-bit application inside the WinXP not starting with error 0001:02C9

The problem occurs on CPU's:
Intel Core I7-7500U
Intel Celeron G3900


But there is no problem with (host CPU and OS):
Intel Core I5-3570K CPU on Win10
Intel Core I3-3110M CPU on Win10

Last edited 4 years ago by ZendX (previous) (diff)

comment:4 by aeichner, 4 years ago

Please attach a VBox.log of the affected VM after you tried to run a 16bit application.

comment:5 by aeichner, 4 years ago

We will probably also need the program you are trying to run. I tried running an arbitrary 16bit DOS game on wo different Intel CPUs (i7-6700K and i5-8350U) and the Windows XP VM ran it just fine.

by ZendX, 4 years ago

Attachment: TestVM-VBox.log added

vbox.log

comment:6 by aeichner, 4 years ago

You seem to have some extradata setting set for the VM, like GuestCpuName for instance and set it to "Intel 80486", is there a particular reason for it? And do you have any other extradata set for your VM?

comment:7 by ZendX, 4 years ago

I played with different settings. In the hope that this will help :) But it did not help me.

comment:8 by aeichner, 4 years ago

In that case we can't do much without access to the 16bit software you are trying to run inside the VM as it doesn't look like a general problem with the XP VDM in general.

comment:9 by ZendX, 4 years ago

How can I give you access to this software?

comment:10 by aeichner, 4 years ago

Maybe you can upload it somewhere (password protected). You can send me the link to alexander (dot) eichner (at) oracle (dot) com or if it is not too big just send me the thing directly along with some instructions on how to set it up and use it to reproduce the crash.

comment:11 by CBingham, 4 years ago

I am having the same problem as cited in this ticket. Since I didn't see any evidence that you got the offending 16-bit software to look at, I tried to send you my example, via the email address in the thread, but never received a response. Sierra Nevada South works on a 2011 Windows 7 computer (host) with Windows XP home premium (guest), but I'm having trouble with a new Win. 10 machine, same guest. I'm running a VirtualBox version that I downloaded today (previously I was running an earlier version, but the problem persists). The first time I try to open the app after installing it, or after rebooting the VM, I get this error message: Sierra caused a GPF at in WIN87EM.DLL at 0001:02C9...Sierra will close.. It shows a "Graphics Server" open on the task bar. Then after I hit "close" then try again to open the app, I get this: Can't load Custom Control c:\mtnimage\mivbx.vbx. Then: Unexpected error; quitting. I've tried changing compatibility settings, but no luck. Right now it's set to Windows 95. Suggestions?

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use