locked
General Protection Fault in module WIN87EM.DLL while Running Windows XP Mode RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    1
    Sign in to vote

    I am attempting to run a legacy, 16-bit program, P3, on a Windows XP Mode Virtual Machine, hosted by a Windows 7 x64 box. When performing various activities in the program, I receive "P3 caused a General Protection Fault in module WIN87EM.DLL at 0001:02C6." This occurs on multiple platforms (Core i5, Core 2 Duo).

    Based on my research, I have found "The Windows 80x87 emulator library, WIN87EM.DLL, works at the 16-bit-Windows level to virtualize the coprocessor among multiple Windows-based applications that run inside the system VM."

    It appears to me that, with the Virtual Machine using a Virtualized Processor (not related to the above reference to "virtualized coprocessor") as opposed to an emulated processor, the Virtual Math Coprocessor Device (VMCPD) and/or WIN87EM.DLL generate an error from the virtualized processor (perhaps they do no recognize it?)

    In addition "When the kernel loads an application, it checks to see if floating-point hardware is present. If a coprocessor is not present, the kernel uses the fixup records to replace the actual floating-point instructions with Interrupt 3x calls to emulation code in WIN87EM.DLL."

    I have found some information that points to "hiding" the math coprocessor from the Virtual Machine, so it doesn't go to the processor. This apparently can be achieved by using a program called WinFloat which includes a tool called HIDE87, which is suppose to hide the math coprocessor from the kernal.

    The issue I'm running into is, to properly achieve this, HIDE87 must be loaded before Windows. I have tried a couple techniques, but I think I'm doing it wrong. I have tried adding the HIDE87 program to the System32 directory and then adding HIDE87 (just before autocheck autochk *) to BootExecute under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager key.

    For a little more info, when you run HIDE87 from the command prompt it reads "HIDE87: Int 11h hook installed (must reboot to remove)." The documentation says this is what needs to occur before Windows loads. You can find WinFloat here: http://support.microsoft.com/kb/97265.

    Any help or insight would be greatly appreciated.

    Wednesday, August 10, 2011 2:39 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    winfloat was designed for and only runs under the DOS based Windows
    like Win3.1, not for Windows XP.
     
    You might have to use an older OS like Windows 98 to run your 16-bit
    program.
     
     
    Bob Comer - Microsoft MVP Virtual Machine
    • Marked as answer by Leo Huang Wednesday, August 17, 2011 7:09 AM
    Wednesday, August 10, 2011 2:58 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    To add to Bob's reply, you might be hitting a CPU feature that isn't passed through to the VM.
    • Marked as answer by Leo Huang Wednesday, August 17, 2011 7:09 AM
    Wednesday, August 10, 2011 5:25 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    winfloat was designed for and only runs under the DOS based Windows
    like Win3.1, not for Windows XP.
     
    You might have to use an older OS like Windows 98 to run your 16-bit
    program.
     
     
    Bob Comer - Microsoft MVP Virtual Machine
    • Marked as answer by Leo Huang Wednesday, August 17, 2011 7:09 AM
    Wednesday, August 10, 2011 2:58 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    To add to Bob's reply, you might be hitting a CPU feature that isn't passed through to the VM.
    • Marked as answer by Leo Huang Wednesday, August 17, 2011 7:09 AM
    Wednesday, August 10, 2011 5:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Maybe then I need to rephrase my question. My goal is not to run winfloat, but to run a 16-bit program called P3 using a Windows XP Virtual PC (Windows XP Mode) on a Windows 7 x64 machine. The program itself runs under ntvdm.exe (NT Virtual DOS Machine) and along side wowexec.exe (which appears to also run under ntvdm.exe).

    When I go to perform certain activities, the program crashes and gives me a "P3 caused a General Protection Fault in module WIN87EM.DLL at 0001:02C6."

    As the program runs fine on a physical Windows XP SP3 machine, my suspicions pointed towards the virtualized  environment. When I researched WIN87EM.DLL and discovered it is used with Windows 16-bit processes to utilize the CPU's math coprocessor, it seemed like the logical conclusion that WIN87EM.DLL and the virtualized processor were not playing nicely, which lead me to winfloat.exe.

    Maybe that's not the answer, but I am curious why this program won't run on a virtualized XP machine when it runs just fine on a physical XP machine. i tried taking an older copy of WIN87EM.DLL from a physical XP machine to see if that helped, but it didn't.

    I've run traces, but it's hard to really tell whats going on as Process Monitor appears to only see 32-bit process therefore all activity appears to be coming from ntvdm.exe.

    Wednesday, August 17, 2011 11:24 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    A virtualized CPU isn't 100% feature complete, so there are edge cases where things don't work.  Each vendor is slightly different in its implementation, so you might have success in VMWare Workstation, Parallels Workstation, or Oracle VirtualBox.

     

    Thursday, August 18, 2011 1:06 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    That's a very good point and very valuable information, smjain. I may have to look at other Virtual Machine solutions, but you can see why I was trying to use WinFloat to block the access of the program to the CPU's Math Coprocessor. If I can hide the Math coprocessor, I just might be able to trick the program into working.

    All other features work and I actually have it deployed to at least 10 Virtual machines, but these are light work duty. I'm trying to move my last two employees in my whole orginization to Windows 7 x64. I left them for last because they were likely to be the trickiest for this exact reason. They are power users on this program and in tests were able to uncover this flaw in a matter of hours.

    Should I just go with a VMWare Workstation and be done with it (after testing, of course)? Or could there be any hope in at least getting HIDE87 to function to at least test?

    Thanks so much for everybody's comments.

    Thursday, August 18, 2011 2:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    What happens if you disable the "Numeric Data Processor" in the system
    devices?  (in the XP VM, not on the host)
     
    I haven't tested it myself yet, but it might be worth a try.
     
     
    Bob Comer - Microsoft MVP Virtual Machine
    Thursday, August 18, 2011 3:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Turning the Numberic Data Processor off did not help fix the problem, however, with your info on WinFloat being a DOS tool, I see now that when I run HIDE87, it opens up a ntvdm.exe instance and the DOS prompt changes to 8.3 so it appears that it moves into that instance. Then, If I run HIDE87 again it tells me: HIDE87 activated - coprocessor masking on.

    Obviously, at this point the challenge is to get the other process to open in THIS NT Virtual DOS Machine, but of course, when it opens, it starts a new instance of ntvdm.exe.

    I'm going to see if there is anyway I can pass the argument into the proper ntvdm.exe instance.

    Thursday, August 18, 2011 8:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Instead of trying to hide the coprocessor, try to emulate it.

     

    Check it out:

    http://www.eunet.bg/simtel.net/msdos/emulate-bydate.html

    Look for "q387" at the list.

    Q387 is a coprocessor emulator from Quickware.

    Friday, August 19, 2011 3:45 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    TryLinux - I think you basically hit the Nail on the Head. I've done that, sort of. I tested out VMWare Player and it has been smooth sailing ever since. The problem does not appear and the program does not crash. I assume it is due to how VMWare has written it's processor emulation software vs. Microsoft. The emulation is just better. 

    I've tried to keep things Microsoft, but man, even their free VMWare Player is Awesome, and now that it solves a very critical issue, I will definitely consider VMWare for future solutions (sorry to sound like a commercial, just very happy.)

    Thanks all for you help and time, it is greatly appreciated and I've learned a lot.

    Thursday, August 25, 2011 4:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Not necessarily better, but different for sure.  There are/have been things that work under VPC but didn't work under VM Ware Workstation.

    The biggest one used to be OS/2, before MS bought VPC, OS/2 support was one of the biggest reasons customers were buying VPC.

    Friday, August 26, 2011 3:24 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    tstock_sjc - I was hanging on to each word then you left me hanging.  How did you solve your problem?  I am having the same problem and would love to make it go away.  Thanks!
    Tuesday, August 30, 2011 11:59 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    great you found this to work.. to bad it is a broken link now and is a waste of time now, awesome that the internet is here to troll us.
    Friday, July 27, 2012 8:46 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    they provided a link that is now broken. i will be looking up other sources useing the search of "emulate-bydate.html" as that was what seemed to have worked for them.

    ok here is the updated link   http://www.lanet.lv/simtel.net/msdos/emulate-bydate.html

    nvm that is a garbage link.... 

    ok found it here....

    http://www.scovetta.com/archives/simtelnet/msdos/emulate/

    • Edited by grumm Friday, July 27, 2012 8:58 PM updated
    Friday, July 27, 2012 8:48 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    just hit back after typing in a lot on my keys all missing keyboard..... 

    because vmware player ignores autoexec.bat and config.sys they do not load this q387.exe, and no real documentation is provided, q387 does not have a .sys file to load as a device and documentatin deals with real computers not virtual machine, vmware has no good documentation regarding alternate booting and useing config and autoexec.

    startup scripting points to files that state not to change then directly yet do not suggest the config program to do indirect changeing.

    perhaps the question should be answered with a clearer explanation containing steps that were taken in full.

    when i get this q387.exe actually running i shall return and compleatly enter the steps (even tho my keys are all riped off my laptop and miss type a lot.

    Thursday, August 2, 2012 2:04 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hello Friends!

    Previously only worked on XPMODE machine with Virtualization enabled in the BIOS.
    The microsoft recently released an update to XPMODE, which makes the virtual windows running on processors without the virtualization capability.
    This update installed on a computer that has DISABLED virtualization in bios, can make it happen this error on 16-bit system (WIN87EM.DLL at 0001:02C6." ).

    I solved this problem above, simply activating the INTEL VIRTUALIZATION computer BIOS. Immediately the error mentioned above stopped happening.

    The culprit in the story was the motherboard that came with virtualization disabled.
    The second culprit is the microsoft, which launched this update, that makes you forget to enable Virtualization in the BIOS, because xpmode works anyway.

    Cassiano Souza

    Vitória - ES - BRASIL SIL SIL!

    Monday, December 3, 2012 11:23 PM
  • Question
    Sign in to vote
    7
    Sign in to vote
    This link helped point me to winfloat to solve the very same issue with WIN87EM.dll crashing under Windows XP on VMware 5 for an old legacy Windows 3.1.  I thought I would mention that the original approach taken by tstock_sjc should work fine.   First off, winfloat is a self extracting executable and we really don't want to run winfloat, but rather hide87.com which is a tiny TSR that is inside the winfloat archive.  When you run any DOS or Windows 3.1 executable, Windows XP first boots up (if one isn't already running) a mini-MSDOS 5 environment called NTVDM.exe.   Just as with the original MSDOS, when the shell loads, it loads files similar to config.sys and autoexec.bat.   Of course, there are more restrictions on drivers and not everything under MSDOS is emulated but nevertheless, it is a fairly good approximation of an MSDOS 5 environment.  The issue that tstock_sjc had was NTVDM.exe looks for %WINDIR%\system32\autoexec.nt and %WINDIR%\system32\config.nt instead of autoexec.bat and config.sys.  If you extract hide87.com out of winfloat.exe and place it into the %WINDIR%\system32 directory and add a line like %SystemRoot%\system32\hide87.com to the end of autoexec.nt , NTVDM will indeed load this TSR before launching its emulated copy of of Windows 3.1 (wowexec.exe).  When the 16 bit application is finally launched after wowexec.exe, the coprocessor is then masked.  It worked fine for me anyway (after applying changes and rebooting).  Under process monitor I could clearly see NTVDM.exe reading autoexec.nt and hide87.com and the WIN87EM.dll GP fault went away. 
    Thursday, September 26, 2013 3:20 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Bruce,

    I am looking at a similar issue and would like to try the winfloat/ hide87.com route to see if i can mask the coprocessor from my NTVDM and allow my 16bit application to run .the Problem is i cannot for the life of me find winfloat.exe to download from the links given above o anywhere else.

    Do you know where i could get this program does anyone on this Forum have a copy still?

    Thanks

    Al

    Monday, March 10, 2014 12:29 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Al,

    we fixed the problem with the solution from Bruce!
    Thanks a lot!

    You can find the winfloat.exe e.g.: http://www.conradshome.com/win31/archive/

    Regards

    Monday, March 24, 2014 3:04 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey,

    This solution, is great. I hade the same problem wit ha 16 bit program on Windows 7 x 32 bit. After using Bruce solution, the error is gone aan the program starts.

    Thanks a lot guys.

    I try it now on x 64 Windows 7


    • Edited by Maximus K Thursday, April 17, 2014 1:31 PM
    Thursday, April 17, 2014 1:31 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi, After using Bruce solution, the error is gone a an the program starts.... But now have another error window "Overflow"  and not load program..... in my casehere, I identified that both errors occur not disabling extension monitor (Dual Monitor) or extension is at the position (side) left. I am studying a  way to temporarily disable the extension but if someone can help with any tips how to solve this.

    thanks


    • Edited by Dmatrix_br Wednesday, April 23, 2014 12:51 PM
    Wednesday, April 23, 2014 12:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Perfect solution from Bruce!

    My situation:

    Windows 2008 HyperV server + Windows XP virtual machine + stupid auto catalog ;) I have this error in auto catalog software ;(((

    My solution (in every virtual machine):

    1. copy HIDE87.com to windows\system32 directory

    2. add to c:\windows\system32\autoexec.nt file FIRST line:

    LH C:\WINDOWS\SYSTEM32\HIDE87.COM

    reboot virtual machine

    3. all works fine ;) THANKS

    Sunday, April 27, 2014 1:23 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks Bruce, your solution fix my issue.

    I just need to start hide87.com before Win under dos.

    Use :  Win 3.11 under VMWare Workstation 9.0

    THANKS

    Monday, May 26, 2014 3:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi, does it makes any difference if i add %SystemRoot%\system32\hide87.com in the end line just like bruce says and what you says to add the command in the FIRST line?

    Thanks.

    Thursday, May 29, 2014 9:42 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Regarding Bruce Zikmund's provide answer from Thursday, September 26, 2013 3:20 AM.

    This worked like a charm for me. I appreciate it.

    Particularly appreciated are the details about HOW to implement the hide87.com. I am not sure I would have figured that part out.
    • Edited by rhanby Friday, August 1, 2014 7:31 PM Clarification
    Friday, August 1, 2014 7:29 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thank you so much for this comprehensive and fine working solution!

    I had the problem, that I wanted to use an old 8-bit windows program (MaxonCAD, mcw.exe, written for win3.1, very old but very mighty and small) under windows 7 32bit. It failed with GFP of Win87EM.dll and following NTVDM fault. I bought a new PC with generation 4 i5-4290T cpu and trapped into this problem.

    This program was the only reason to no go to 64bit architectures. No I can stay with windows for a next while and don´t need to step back to 3rd generation cpus.

    TXS again.

    Wednesday, January 21, 2015 8:09 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    HELLO I AM HAVING THE SAME ISSUE I HAVE A VIRTUAL MACHINE ON MAC CALLED PARALLELS WITH WINDOWS XP SP3 I INSTALLED MANY PROGRAMS CALLED MICROCATS, BUT ONE OF THEM WHEN I TRY TO OPEN KEEP GIVING THE WIN87EM.DLL ERROR, DID YOU FIX THIS PROBLEM??

    PLEASE HELP ME OUT THANKS

    Monday, March 30, 2015 9:22 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Disabling the Numeric Data Processor in Windows Device manager worked for me. After "hiding" the math coprocessor the application (in this case Stylus by Insignia) would stop responding.

    Thanks for the thread guys this post ultimately helped me find the solution.

    - Jeremy

    Wednesday, September 30, 2015 6:10 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Jeremy,

      We are having this exact same issue with Stylus, on a 32-bit Win 7 VM, however, I do not see the Numeric Data Processor listed under Manage > System Devices is this where you found this?

    Monday, December 12, 2016 10:46 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    after I apply the changes, the software tells me LABWIEW requires a math coprocessor. if there is another solution for this problem, many thanks!
    Monday, November 6, 2017 5:53 AM