EGPFault in win87EM.dll bei neuen Intel-CPUs und allen VMware-Player Versionen

Problem-Kurzbeschreibung und betroffene Anwendungen:

EGPFault in win87EM.dll auf allen Computern mit neueren Intel-CPUs ab Haswell (2013) bei Borland-Delphi-1.6-Programmen auf Windows XP in allen VMware-Player-Versionen

Das Problem tritt auf beim Compilieren von Borland-Delphi-1.6-Programmen in Windows XP in VMs aller VMware-Player-Versionen, in VirtualBox und Windows-XP-Mode mit Windows Virtual PC, sowie auch bei CAD ESTIMATOR (CADEST), älteren 16bit- Finanzprogrammen wie FIBU und älteren 16bit-Anwendungen für Spiele.
Dass Problem trat auf diesen Host-Betriebsystemen auf: Windows 7 prof. 64 bit, Windows 8.1, Windows 10 Home 64 bit.

Auf Host-Intel-CPUs vor Haswell (2013) gibt es den EGPFault in win87EM.dll nicht:
Ich habe am 27.8.2008 einen Tower PC mit der CPU "Intel Core 2 Quad Q6600 2,4GHz" gekauft.
Die für mich wichtigste Anwendung auf diesem PC vom Jahr 2008 ist ein seit über 20 Jahren und auch jetzt noch von mir weiter entwickeltes objektorientiertes Finanz-Programm, eine 16bit-Anwendung, programmiert in Borland Delphi 1.6, welche heute nur mehr in virtuellen Maschinen mit Windows XP in VMware Player läuft. Auf diesem PC gibt es das Problem EGPFault in win87EM.dll deshalb noch nicht, weil die CPU noch vor 2013 von Intel auf den Markt gebracht wurde. Auch auf einem Lenovo Thinkpad X1 ( gekauft 2011) ist das Problem noch nicht vorhanden, weil die CPU
Intel Core i5-2520M Sandy Bridge-MB SV noch vor 2013 entwickelt wurde.

Bei allen neueren Intel-CPUs ab (inkl.) Haswell am Host:
EGPFault in win87EM.dll in allen VMs aller VMware-Versionen

Für den mobilen Einsatz und als Reserve-Computer habe ich inzwischen 2 Ultra-Books mit neueren Intel-Prozessoren gekauft, auf welchen ich leider bis heute Delphi 1.6 Programme nicht mehr kompilieren kann, da beim Compilieren die Meldung kommt:

Im Projekt DESTOCKS.EXE ist eine Exception der Klasse EGPFauIt aufgetreten. Meldung:
'Allgemeine Schutzverletzung in Modul WIN87EM.DLL bei 0001 :02CA'.

• Lenovo Yoga 3 Pro, mit Intel(R) Processor 5Y70 CPU @ 1.10GHz; Broadwell Y, CPU ID: 000306D4,
gekauft am 9.6.2015
• Toshiba Portégé Z30-C-138, mit Intel Core-2600 Skylake-Y
CPU Brand Name: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz,
CPU ID: 000406E3, gekauft am 13.3.2016

Bereits compilierte Programme laufen auf PCs mit neuen Intel-CPUs nur kurz und brechen ohne Fehlermeldung an immer anderen Stellen ab. Während ich bis Mitte Mai 2016 das Problem trotz großen Zeitaufwandes seit über einem Jahr vergeblich in den Einstellungen oder der Version von VMware-Player, Windows XP Mode oder VirtualBox gesucht habe, habe ich nun im Internet bei Foren von VMware.com und virtualbox.org die wahre Ursache gefunden: alle neueren Intel-Prozessoren ab und inkl. Haswell-CPU (ab 2013) haben einen "Bug", der diesen EGPFault in WIN87EM.DLL verursacht, und keine VM-Software ist derzeit in der Lage, ihn zu verhindern :

In some circumstances, the WIN87EM.DLL 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. Loading from a NULL code segment is illegal, and the result is a general protection fault.
One reason for a NULL code segment is that you may be running on modern Intel CPUs with FCS/FDS deprecation [sic]. Beginning with Haswell CPUs, Intel no longer saves the code segment of the last FPU instruction executed (or the last FPU instruction to generate an exception) in the FPU environment. On such hardware, you would encounter the general protection fault natively as well as in a VM. A potential workaround is to hide the X87 coprocessor from the application. For more information on this workaround, search the internet for "win87em.dll general protection fault hide87.com". Of course, performance will be adversely impacted, since all floating point operations will be emulated.
Eingefügt aus <https://communities.vmware.com/people/jmattson/blog/2012/03>


Zwei weitere Quellen, welche das Unterschlagen des Code-Segments der letzten FPU-Instruktion bei allen derzeitigen neuen Intel-CPUs am Markt als Ursache für den EGPFault in WIN87EM.DLL aufzeigen, sind:
https://forums.virtualbox.org/viewtopic.php?f=2&t=59741&start=30 und
http://stackoverflow.com/questions/10511506/old-16-bit-application-caus ...

Nicht erfolgreicher Lösungsversuch durch ältere Win87EM.dll
Die auf https://support.microsoft.com/de-de/kb/86869 vorgeschlagene Lösung, die WIN87EM.DLL durch eine ältere Version von 1992 zu ersetzen, hat sich bei mir im Mai 2016 als unwirksam erwiesen.

Deaktivieren des Math-CoProzessors stoppt den EGPFault in win87EM.dll auf Kosten der Performance:

Ich konnte den EGPFault in WIN87EM.DLL mit einem Workaround reproduzierbar wegbekommen, bei welchem der Mathematik-CoProzessor deaktiviert wird, und die CoProzessor-Funktionen nur softwaremäßig emuliert werden. Nach Hinzufügen von “lh c:\windows\system32\HIDE87.com” in die Datei “autoexec.nt” verschwindet der GPF in WIN87EM.DLL. Diese "Lösung" macht das sehr rechenintensive Programm jedoch so langsam, das es dadurch unbrauchbar wird.

Kann VMware (Player) ohne Performanceverlust ältere Intel-CPUs vor Haswell emulieren?
Gibt es jetzt schon eine kostenpflichtige VMware-Version (z.B. Workstation?) , welche den Intel-Bug in der Host-CPU eventuell durch Emulieren einer älteren Intel-CPU oder einer AMD-CPU in der VM wirkungslos machen kann?  Alle meine bisherigen Versuche waren auf die kostenlosen VM-Programme VMware-Player, VirtualBox und Windows-XP-Mode beschränkt.
 
Fragen an Forum-User: Gibt es das Problem auf neueren AMD-CPUs (z.B. Carrizo) nicht?
Bis Intel wieder Prozessoren ohne diesen Bug auf den Markt bringt, oder eventuell doch noch VMware- oder VirtualBox-Entwickler das Problem lösen können, ist der einzig gangbare Weg, um mein Finanz-Programm auch dann noch weiterentwickeln zu können, wenn der 2008 gekaufte PC den Geist aufgibt, ist der Kauf folgenden Notebooks mit AMD-Prozessor, da laut Forum VirtualBox.org AMD-Prozessoren vermutlich (jedoch noch nicht ganz sicher bestätigt) frei von dem Fehler sind:

HP EliteBook 745 G3, A12 PRO-8800B, 8GB RAM, 256GB SSD (T4H61EA#ABD) (Prozessor Codename Carrizo )
Preis bei Cyberport.at 1299,99 € inkl. Versand.

Damit ich nicht ein drittes Notebook kaufe, das ich dann wieder wegen Unbrauchbarkeit verkaufen muss, müsste vor dem Kauf wie folgt in nur ca. 3 Minuten getestet werden, ob der AMD-Prozessor A12 PRO-8800B nicht auch das gleiche Problem wie die neuen Intel-Prozessoren hat:

Mit der kostenlosen portablen Software HWiNFO32 kann man reproduzierbar feststellen, ob ein Computer diesen Prozessorfehler hat. Ich habe das an 2 neuen Intel-PCs mit und an 2 alten Intel-CPUs ohne diesen Prozessorfehler reproduzierbar ausgetestet:
http://www.hwinfo.com/download.php Portable 32bit-Version oder 64bit-version downloaden von http://www.fosshub.com/HWiNFO.html

Nur die Zeile "Deprecated FPU CS and FPU DS" mit "Present" oder "Not Present" im HWInfo32-Report lässt erkennen, ob der Prozessor den Fehler hat oder nicht hat . Daraus kann man dann schließen, ob man das HP EliteBook 745 G3, A12 PRO-8800B, 8GB RAM, 256GB SSD (T4H61EA#ABD) kaufen kann oder nicht oder auch ein ähnlichen Computer mit einer neueren AMD-CPU.
Hat jemand ein HP EliteBook 745 G3 mit CPU A12 PRO-8800B zur Verfügung, wo er einen HWInfo32-CPU-Report machen kann? Wenn ja, steht in der Zeile "Deprecated FPU CS and FPU DS" "Present" oder "Not Present"?