ISim stürzt nur noch ab (ISE 12.1 und ISE 12.4)

[Anguel S. (anguel)]

Hallo Leute!

Habe ein sehr blödes Problem und komme nicht weiter. Vor ein paar Tagen 
lief auf demselben Rechner alles super, jetzt stürzt ISim in ISE 12.1 
und 12.4 nur noch ab. Egal welches Projekt und welcher Spartan. Das 
Problem trat ganz plötzlich bei der ISE 12.1 auf, hab dann auch 12.4 
installiert, genau das gleiche Problem. In 11.1 läuft er dagegen noch 
und auf einem anderen Rechner läuft es auch problemlos.

Habe die Absturz-Screenshots beigefügt. Die Microsoft Visual C++ Runtime 
Library meldet "runtime error" und "abnormal program termination" in der 
<testbench>.exe die von ISim erzeugt wird. Habe die Visual C++ 
Redistributables deinstalliert neu installiert - bringt nix, der lädt 
sie laut Process Explorer sowieso immer aus 
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053 
_x-ww_e6967989.

Isim.log zeit folgendes:
---
...
This is a Lite version of ISim.
Time resolution is 1 fs
# onerror resume
# wave add /
No active Database
# run 500 ms
Unable to execute live simulation command.
---

Hab ein simples Projekt mit den gleichen Parametern erzeugt und hab es 
mal auf dem funktionierenden Rechner und auf dem nicht funktionierenden 
Rechner getestet. Die erzeugten Dateien unterscheiden sich nicht groß, 
aber die *.exe Datei im *.exe.sim Verzeichnis, die den Absturz 
verursacht unterscheidet sich schon geringfügig. Auch die erzeugte *.wdb 
(Database?) Datei auf dem kaputten Rechner ist leer. Frage ist, ob das 
die Ursache oder eine Folge des Absturzes ist.

Hab auch alle Projektdateien vom funktionierenden Rechner kopiert und 
diese auf dem kaputten über Kommandozeile ausgeführt:
"isim_crash_test_isim_beh.exe" -gui -tclbatch isim.cmd -wdb 
"isim_crash_test_isim_beh.wdb"
Die <testbench>.exe crasht wieder, scheint IMHO also eher ein Bug in 
ISim zu sein, und nicht in den Zusatzdateien, die er erzeugt.

isimcrash.log auf dem kaputten Rechner enthält immer das gleiche:
Exception at PC 0x7C812AFB
hab mal danach gegooglet, haben wohl auch andere Leute aber keine Lösung 
oder Kommentar dazu gefunden.

Hab ansonsten so ziemlich alles aus der Xilinx Knowledgebase 
durchgetestet, ohne Erfolg. Im Xilinx-Forum hat mir bisher auch niemand 
geantwortet.

Danke für jede Hilfe!

Grüße
Anguel

[Duke Scarring (Gast)]

Anguel S. schrieb:
> Auch die erzeugte *.wdb
> (Database?) Datei auf dem kaputten Rechner ist leer. Frage ist, ob das
> die Ursache oder eine Folge des Absturzes ist.

Das ist eine Folge des Absturzes. Simuliert denn das Projekt auf dem 
funktionierenden Rechner richtig?

Duke

[B. G. (smarti)]

Hallo,

ich hatte auch schon Problme dass ISim gechrasht ist, allerdings nicht 
so massiv.

Gennerell hilft auch das Projekt zu cleanen:

Versuch mal in der ISE: "Project" -> "Cleanup Project Files"

Oder die Projektdateien komplett zu verwerfen und neu aufzusetzen.

Letzte Möglichkeit: Fehler im Design.

Persönlich habe ich es durch Copy & Paste geschaft, in Verilog ein Modul 
Entry so zuverhauen, das die ISE immer beim laden des Projects gechrasht 
hat.

Grüßle Smarti

[Anguel S. (anguel)]

Duke Scarring schrieb:
> Anguel S. schrieb:
>> Auch die erzeugte *.wdb
>> (Database?) Datei auf dem kaputten Rechner ist leer. Frage ist, ob das
>> die Ursache oder eine Folge des Absturzes ist.
>
> Das ist eine Folge des Absturzes. Simuliert denn das Projekt auf dem
> funktionierenden Rechner richtig?

Ja, es simuliert auch das "kaputte" Projekt immer richtig auf dem guten 
Rechner. Füllt sogar die wdb Datei auf.

Nebenbei bemerkt: Wenn ich die settings32.bat (neu bei ISE 12) nicht 
vorher ausführe, also wenn die Xilinx Pfade nicht im PATH sind, kommt 
eine Art Absturz beim Ausführen von "isim_crash_test_isim_beh.exe" -gui 
-tclbatch isim.cmd -wdb "isim_crash_test_isim_beh.wdb" auf der 
Kommandozeile (siehe Screenshot). Das passiert aber gleich auf beiden 
Rechnern, scheint also "normal" zu sein und wird bei euch denke ich 
nicht anders sein. Der zweite und für mich fatale Absturz mit Visual C++ 
Runtime kommt aber nur auf dem "kaputten" Rechner :(

Übrigens ist mir gar nicht klar, was dieses blöde settings32.bat 
überhaupt soll, denn sobald das cmd Fenster zugeht sind diese 
Pfadangaben anscheinend wieder weg. Testet das mal. Xilinx behauptet, 
dass diese settings32.bat immer beim Start von Project Navigator vorher 
ausgeführt wird, damit der Pfad in PATH reinkommt. Wenn ich dann aber 
ein neues cmd Fenster öffne und path auf der Kommandozeile ausführe, 
steht da der Xilinx Pfad nicht mehr drin...

[Anguel S. (anguel)]

B. G. schrieb:
> Gennerell hilft auch das Projekt zu cleanen:
>
> Versuch mal in der ISE: "Project" -> "Cleanup Project Files"

Bringt nix.

> Oder die Projektdateien komplett zu verwerfen und neu aufzusetzen.
Komplett neues Projekt = wieder Absturz.

> Letzte Möglichkeit: Fehler im Design.
Ein Design, das praktisch leer ist, führt auch zum Absturz. Kann also 
nicht sein.

[Christian R. (supachris)]

Anguel S. schrieb:
> Übrigens ist mir gar nicht klar, was dieses blöde settings32.bat
> überhaupt soll

Eigentlich braucht man die nur auf x64 Systemen. Denn Xilinx liefert 
mittlerweile fast alle Programme auch als native x64 Binaries aus. Die 
befinden sich im nt64 Ordner, und die Pfade müssen stimmen, wenn du den 
Projekt Navigator x64 aufrufst, muss er auch xst, map, ngdbuild usw. aus 
dem nt64 Ordner benutzen. Man kann ja auch unter x64 die 32-Bit 
Programme benutzen. Kann man natürlich auch einmal in den 
Umgebungsvariablen fest einstellen und gut ist.

[Anguel S. (anguel)]

So, habe das ganze als WebCase an Xilinx gemeldet. Darf man sowas 
eigentlich als WebPack User? :) Ich habe das angefordert und die haben 
es mir erlaubt. Aber schließlich helfe ich denen ja, ihr Produkt zu 
debuggen.

[Xenu (Gast)]

Selbst ist der Mann. Hol Dir den Process Monitor und schau mal
was kommt. Im Filter (CTRL+L) stellst Du "Process Name" auf "isim".

Das Tool hat mir schon oft geholfen. Und schaden tut's nicht.

http://technet.microsoft.com/de-de/sysinternals/bb896645

[Anguel S. (anguel)]

Xenu schrieb:
> Selbst ist der Mann. Hol Dir den Process Monitor und schau mal
> was kommt. Im Filter (CTRL+L) stellst Du "Process Name" auf "isim".
>
> Das Tool hat mir schon oft geholfen. Und schaden tut's nicht.

Hab das mal laufen lassen, kommen aber ca. 17.000 Meldungen. Soll ich da 
nach was speziellem suchen?

[Anguel S. (anguel)]

Verdammt! Problem gelöst! Werdet ihr es mir glauben, wenn ich euch sage, 
dass sich eine RSLSP.dll, die von StationRipper in C:\WINDOWS\system32\ 
installiert wird, irgendwie in ISim einhakt und den Crash verursacht?

Hab das Ding grade auf VirusTotal hochgeschickt aber keine Engin meldet 
einen Virus...

Danke an Xenu für die Idee mit Process Monitor, hatte mir das ganze 
schon vorher mal mit Process Explorer angeschaut, aber das hat mich 
jetzt dazu gebracht, doch mal zu vergleichen, was so alles geladen 
wurde.

[Anguel S. (anguel)]

Dieser StationRipper scheint irgendeinen Komodia LSP Dienst zu nutzen, 
der vermutlich das ganze verursacht...