mein Arbeitgeber hat vor zwei Wochen seine Clipper-Programme auf Xbase umgestellt, und zunächst schien alles super zu laufen. Dann aber wurden immer mehr Arbeitsplätze mit neuen Rechnern und Windows 10 ausgestattet, und an diesen Arbeitsplätzen - und NUR an diesen - gibt es nun regelmäßig Abstürze.
Diese Abstürze ereignen sich nur sporadisch (bei geschätzten 50 Aufrufen von Xbase-Programmen pro User an einem Arbeitstag vielleicht ein oder zwei Abstürze).
Die Abstürze hinterlassen keine Fehlermeldung und kein xpperror.log, sondern das Programm bleibt einfach hängen.
Die Abstürze ereignen sich immer sofort nach dem Start des Programms, also noch bevor das Programm dazu kommt, etwas auf den Bildschirm, besser gesagt in sein Fenster zu schreiben. (Deshalb nennen wird das Phänomen "schwarzer Bildschirm".)
Wir haben festgestellt, dass abstürzende Programme nicht immer "gleich weit" kommen, sondern an verschiedenen Stellen in den Startroutinen "aufgeben".
Es sind die unterschiedlichsten Xbase-Programme betroffen (die allerdings in ihren Startroutinen übereinstimmen).
Wenn ein Xbase-Programm in einen "schwarzen Bildschirm" gelaufen ist, dann läuft auch jedes weitere Xbase-Programm, das der User danach noch zu starten versucht, in einen "schwarzen Bildschirm". Dann hilft nur noch, den Rechner neu zu starten.
Das Problem tritt nur an unseren neuen Rechnern (HP ProDesk 400) mit Windows-10-Pro Version 2004 auf. Vor der Umstellung hatte ich an einem anderen Rechnermodell mit Windows-10-Pro Version 1903 getestet, ohne dass der Fehler auftrat. Wir haben auch noch Rechner im Netzwerk, die mit Windows 7 und Windows XP arbeiten, und auch an diesen tritt der Fehler nicht auf.
Der Fehler tritt unabhängig von der Skalierung des Bildschirms auf.
Die Abstürze kann ich mit einem Hilfsprogramm provozieren: Das Hilfsprogramm ruft alle 3 Sekunden ein anderes Hilfsprogramm auf, das nur ein bißchen protokolliert und sich beendet. Der Fehler tritt manchmal schon nach 3 Minuten, manchmal auch erst nach 30 Minuten auf.
Wenn ich mir, während dieses Hilfsprogramm läuft, mit dem Taskmanager die Anzahl der Prozesse, Threads, Handles ansehe, ist kein Anstieg zu bemerken.
Wir haben auch einen User, bei dem der Fehler sofort beim ersten Versuch, ein Xbase-Programm aufzurufen, auftrat.
Hat das jemand von euch schon erlebt?
Oder eine Idee, was die Ursache sein könnte?
Liebe Grüße, bleibt gesund
Martin
[Edit: "Erledigt" eingetragen.]
Zuletzt geändert von komnick am Mo, 28. Sep 2020 13:05, insgesamt 2-mal geändert.
Martin,
welche Xbase++-Version?
Wie lange habt ihr bis zum Neustart des Rechners gewartet? Ab und an habe ich diese Phänomene mit (z.B.) Thunderbird. Nach gut 40 Sekunden (gefühlt) geht es aber normal weiter.
Ich denke schon, dass in einigen Fällen einige Minuten gewartet wurde. Einige User haben sich bei mir gemeldet und ich bin zu deren Arbeitsplatz hinübergegangen und habe mir das angeguckt... Das hat bestimmt länger als 40sec gedauert.
In der Produktionsumgebung unserer Windows 2008 Citrix Server hängt sich seit ein paar Monaten meine EXE auch immer auf.
Auf dem Testserver und allen anderen PCs inkl. Win 10 neuestes Release kann ich es nicht provozieren, wobei bei uns die EXE komplett aufbaut und auf Eingaben wartet, erst nach Maus oder Eingabe kommt "Anwendung reagiert nicht mehr" ...
wir benutzen die HP ProDesk 400 auch. Ohne jegliche Probleme. Auch mit Win10 2004.
Abweichend zu deiner Konfiguration mit folgenden Unterschieden:
- Die EXE + DLL's sind ausschliesslich unter c:\Programme (x86)
- Die EXE sind alle signiert
- Die PC's laufen mit Windows Defender ohne zusätzlichen Antivirus Programme.
- Einige SMB3 Einstellungen müssen deaktiviert werden: Es sind dies die File- und Directory Caching und Locking Funktionen.
komnick hat geschrieben: ↑Di, 15. Sep 2020 11:45
Grafikkarte: Intel UHD Graphics 630
Intel(R) Core(TM) i3-9100T CPU
suche mal bei Intel, mit dem Driver Assistant, nach neuen Treibern.
auch würde ich mal "ScreenRes" probieren bei einem "schwarzem Bildschirm"
die von Carlo genannten Registry Einträge sind im "Alaska-SMB2-Patch" enthalten bis auf "UtilizeNtCaching" welches gewöhnlich zusammen mit "UseWriteBehind" verwendet wird. das hat aber IMHO nichts mit "schwarzem Bildschirm" zu tun.
AUGE_OHR hat geschrieben: ↑Mi, 16. Sep 2020 9:04
eben NICHT weil der PC Hersteller und Microsoft oft ältere Treiber hat als Intel sie anbietet.
Das mag ja durchaus so sein.
NUR: HP veröffentlicht die Treiber dann wenn diese Firmeninterne Tests durchlaufen haben und "einigermassen" sichergestellt ist dass diese auf dem betreffenden Gerät auch problemlos laufen. Nach meinen Erfahrungen gibt es viele Wege Zeit mit Experimenten und Frust zu vertun. Nicht vom Hersteller der Geräte geprüfte Treiber zu verwenden ist einer davon .........
Vorallem wenn du dann noch ein Support-Ticket öffnen willst geht gleich gar nichts ohne die "Originaltreiber" .....
Vielen Dank für eure Tipps!
Tatsächlich führen uns unsere Untersuchungen hier in eine andere Richtung...
Es schaut so aus, als seien bei uns nur jene Arbeitsplätze betroffen, die einen speziellen Druckertyp (nämlich einen OKI) als Standarddrucker definiert haben. Und tatsächlich ereignen sich die Abstürze auch im Umfeld einer Vorroutine, bei der unser Drucksystem initialisiert wird.
Unsere nächsten Tests werden sein, an einigen Arbeitsplätzen die OKI-Druckertreiber auszutauschen, sowie bei der weiteren Ausstattung von Arbeitsplätzen mit Windows 10 zunächst jene Arbeitsplätze vorzuziehen, die keinen OKI-Drucker haben, um diese Theorie zu untermauern.
(...und ich bin nicht sicher, ob ich hier missverstanden wurde, daher noch einmal klargestellt: Bei unseren Abstürzen ist nicht der ganze Bildschirm schwarz, sondern nur das Xbase-Fenster.)
bei Chip-Satz Treiber sollte man IMHO immer die neusten Treiber des Chip Hersteller nehmen.
unabhängig davon muss man ja die gemeldeten Updates nicht annehmen aber man wüsste dann ob vorhandene aktuell sind.
komnick hat geschrieben: ↑Mi, 16. Sep 2020 10:41
Es schaut so aus, als seien bei uns nur jene Arbeitsplätze betroffen, die einen speziellen Druckertyp (nämlich einen OKI) als Standarddrucker definiert haben. Und tatsächlich ereignen sich die Abstürze auch im Umfeld einer Vorroutine, bei der unser Drucksystem initialisiert wird.
Das wundert mich nun doch ein wenig. Weil den hatten wir mit einigen OKI MFC vor einigen Jahren auch schon. Es handelte sich um Miet-Geräte. Abhilfe brachten andere Treiber welche uns der Anbieter der Geräte besorgt hatte, nachdem er die Geräte eigentlich abholen sollte, danach gabs dann wirklich keine Probleme mehr .......
Auch wenn der Thread schon älter ist: bei mir war es das Update eines PDF Drucker Treibers, der beim Druck Probleme machte. Mit dem Bullzip Treiber klappt nun alles.