EXE funktioniert nicht mehr - MS-Fehlermeldung

[Koverhage]

Roland,

Das Seltsame ist, dass als der Fehler vor einigen Monaten zum ersten Mal auftrat an den Threads nichts gedreht wurde und diese schon seit Jahren laufen. Zumindest soweit ich das zurückverfolgen kann.

Das kann durchaus mit einem Windows Update zusammenhängen (gerade weil die Probleme ja mit Windows Prozessen zusammenhängen)

[DelUser01]

Hallo Martin

werden in diesen problematischen Threads irgendwelche OCX/ActiveX-Komponenten genutzt?

OCX sagt mir in meiner Programmierung nichts. ActiveX verwende ich verschiedentlich. Aber ob das in den Threads irgendwo der Fall glaube ich eher nicht. Das muss ich im Detail überprüfen...
Wüsste aber gar nicht wie ich das herausbekommen soll - schon gar nicht wenn das in einer 3rd-Party-DLL passiert (z.B. TAPI).

[DelUser01]

Hallo Klaus

Das kann durchaus mit einem Windows Update zusammenhängen (gerade weil die Probleme ja mit Windows Prozessen zusammenhängen)

Den Verdacht habe ich auch schon einige Zeit dass das so ist.
Hatte ja schon geschrieben, dass der Fehler plötzlich auch beim MS Internet Explorer aufgetreten ist. Das war aber nach einigen Monaten wieder weg - sicher wieder durch ein Update.

Übel ist einfach, dass es keine Anhaltspunkte gibt mit dem das zusammenhängt. Außer über das Microsoft Ereignisprotokoll.
Bin am überlegen ob ich den kostenpflichtigen Microsoft Partner-Support dazu einschalten soll. Muss aber noch abklären ob die sich mit so einem Problem überhaupt beschäftigen.

Aber hilft ja nichts - so langsam gibts Ärger bei den Kunden...

[HaPe]

Hallo Roland !

Wüsste aber gar nicht wie ich das herausbekommen soll - schon gar nicht wenn das in einer 3rd-Party-DLL passiert (z.B. TAPI).

Mit dem http://www.nirsoft.net/utils/axhelper.html erstellst du dir auf einem nackten System/virtuelle Maschine eine Übersicht der vorhandenen ActiveX-Controls (Ergebnis der Liste in eine Textdatei speichern).
Dann deine Software komplett installieren und nochmals eine Übersicht der vorhandenen ActiveX-Controls mit dem og. Tool erstellen (Ergebnis der Liste wieder in eine Textdatei speichern).
Dann die beiden Textdateien vergleichen => Jetzt hast du alle ActiveX-Controls deiner Anwendung.

[DelUser01]

OK - ich schaue mir das an.

[AUGE_OHR]

das Windows Update Probleme verursachen können ist schon klar ... aber dann müssten auch andere das Problem haben !

wenn Roland aber schon selbst sagt das da noch offene Threads sind dann muss man natürlich erst mal das Problem beseitigen.

evtl hilft auch dieser Registry Eintrag ein wenig mehr Zeit zu verschaffen : HungAppTimeout
https://technet.microsoft.com/en-us/lib ... 78614.aspx

und für das "runterfahren" danach : WaitToKillServiceTimeout
https://technet.microsoft.com/en-us/lib ... 76045.aspx

aber wie schon gesagt verschaffen die einem nur ein wenig mehr Zeit, das "Problem" wird dadurch nicht behoben.

---

wenn ein Thread die ganze Zeit mitläuft dann gibt es vermutlich eine Schleife oder man verwendet o:setInterval()

a.) wenn der Code von einem Thread durch o:setInterval() aufgerufen wird funktioniert auch ein "Schalter" wenn er gleich am Anfang sitzt

b.) bei einer Schleife muss man ja bei Xbase++ aufpassen das nicht die ganze CPU Zeit dabei drauf geht.

ein Mittel dagegen ist ein SLEEP() ... nur sind wir damit noch nicht raus aus der Schleife.
ein "Schalter" oder Function soll ihn nun da raus bringen ... und wenn du Pech hast reagieren "alle sofort"
"alle" wollen jetzt was von Windows OS() und Xbase++, als Schnittstelle, arbeitet nur auf 1 x CPU

b1.) wie schon erwähnt ein AppEvent() in die Schleife einbauen und auf einen (UserDEF) Event reagieren.

wenn ich dem Windows OS() 100 x

Code: Alles auswählen

PostAppEvent( xbeP_Close,,, aObject[i] )

schicke macht er die mir auch sauber zu.

[DelUser01]

Status

Habe es inzwischen geschafft, dass alle Threads bei normalem EXE-Quit vor dem letzten Return in AppExit() beendet sind. Das sagen zumindest die Protokolle.

Mal sehen was der nächste Tag Neues bringt...

Trotzdem ist es ein schöner Mist einen Fehler nicht bei Bedarf reproduzieren zu können.

[ramses]

Hallo Roland

du könntest auch mal versuchen ob ohne die TAPI - Threads der Fehler auch auftritt oder ein Tool einsetzten welches dir die geöffneten Dateien anzeigt, vielleicht kommst du so dem Übeltäter auf die Spur.

Cu Carlo

[DelUser01]

Hallo Carlo

leider tritt der Fehler auch bei denjenigen Usern auf welche keine CTI-Funktionalität haben.
Die TAPI-DLL wird zwar geladen, es wird aber kein TAPI-Connect aufgebaut und die Threads werden nicht gestartet.

[ramses]

Hallo Roland

du könntest noch versuchen die TAPI DLL gar nicht erst zu laden.

Cu Carlo

[DelUser01]

das da noch offene Threads sind dann muss man natürlich erst mal das Problem beseitigen

Threads sind inzwischen alle beendet bei AppExit()

o:setInterval()

Ich verwende kein Interval, nur Sleep() oder AppEvent().

Alle Warte-Schleifen der Threads sind inzwischen so umgestellt, dass innerhalb kürzester Zeit Sleep(10) die Abfrage o:CheckTermination() erfolgt.

[DelUser01]

Hallo Carlo

du könntest noch versuchen die TAPI DLL gar nicht erst zu laden

Habe jetzt erst umfangreich die Thread-Steuerungen geeändert. Jetzt warte ich ab ob der Fehler wieder auftritt.
Wenn ja, dann lasse ich den Zustand der Threads und mache mich an anderer Stelle auf die Suche. Da gehört vorrangig alles mit Kommunikation dazu, also TAPI.

Noch habe ich die Hoffnung dass es die Threads sind/waren...

[AUGE_OHR]

Habe es inzwischen geschafft, dass alle Threads bei normalem EXE-Quit vor dem letzten Return in AppExit() beendet sind. Das sagen zumindest die Protokolle.

Mal sehen was der nächste Tag Neues bringt...

jeder Tag bringt neue Überraschungen

[DelUser01]

Status-Info

Um die Fehlerquelle einzukreisen habe ich mir Gedanken gemacht, was ich Mitte 2016 geändert haben, dass die Abschlussprozeduren bei Quit beeinflussen könnte - und habe was gefunden:

Mitte 2016 habe ich bei mir und bei Kunden den ADS von 10.x auf 12.x aktualisiert.

Vielleicht gibt es Probleme mit dem Terminieren des Connects zum ADS oder so...

[ramses]

Hallo Roland

hast mal versucht die Comm. DLL's aus der Runtime mit den neuen der 12er Version zu ersetzten?
Es sind dies ace32.dll, adsloc32.dll, axcws32.dll diese sollten immer der Version des ADS entsprechen.


Cu Carlo

[DelUser01]

Hallo Carlo

adsloc32.dll

Die habe ich nicht.

Die anderen beiden habe ich aus dem neuen Server-Installationsverzeichniss v12 genommen.

[ramses]

Hallo Roland

adsloc32.dll ist die für Locale-Verbinung (ADS-Local) wenn du nur Remote-Server verwendest brauchts die nicht.

Wir arbeiten noch mit der 10er Version. Aber bei neuen Version gab es früher auch schon mal Probleme, versuch doch mal ein RollBack auf den ADS10, ausser dem Servermodul und den oben besprochenen DLL brauchts nicht mehr.....

Gruss Carlo

[Wolfgang Ciriack]

adsloc32 ist auch nur für den ADS lokal Sever, wenn kein ADS-Server benutzt wird.
Ich hatte Probleme mit den Dateien vom ADS 12.x, daher benutze ich die von 11.x, aber vielleicht sind die ja schon behoben.

[DelUser01]

Hallo Wolfgang

Ich hatte Probleme mit den Dateien vom ADS 12.x

Habe erst vor einigen Monaten die Datei ace32.dll und axcws.dll aktualisiert (v11 auf v12). Den Fehler hatte ich schon vorher.

Was hattest Du für Probleme mit den ADS-Dateien aus v12?

[Wolfgang Ciriack]

Ich bekam keine Verbindung zum ADS. Da mit den 11.x Dateien alles funktionierte, habe ich dann nicht weiter getestet.

[DelUser01]

Status-Update

jetzt ist seit 5 Tagen der Fehler anscheinend nicht mehr aufgetreten – zumindest wurde mir von keinem User der Fehler diese Woche gemeldet. Auch auf meinem Arbeitsplatz ist dieser nicht mehr aufgetreten.

Laut meinen Protokollen ist jetzt kein Thread mehr bis zum letzten Return in AppExit() hängengeblieben.

Ich hoffe das das so bleibt...

[DelUser01]

Status-Update

Schade - treurig aber Wahr - es liegt anscheinend doch nicht an den Threads.
Gerade ist auf meinem Arbeitsplatz der Fehler wieder aufgetreten. Laut Protokoll sind alle Threads beendet.
So ein Mist...

[ramses]

Hallo Roland

ganz am Anfang hast du mal erwähnt dass auch IExplorer dieses Problem hatte.

Könnte es nicht sein dass es sich um ein Hardware oder Windows-Problem handelt?
Siehst du einen zusammenhand zwischen der verwendeten Hardware(Bios/Ram) und den Abstürzen?
Verwendest die die aktuellen Bios/Firmware Versionen?

Kannst du dich an den Hardware-Hersteller wenden?
Ich hatte mal einen Fall da wurde vom Hersteller ein Bios-Update verordnet und die Probleme waren verschwunden......


Gruss Carlo

[DelUser01]

Hallo Carlo

das ist richtig, dass der MS Internet Explorer auch schon diesen Fehler brachte. Aber wesentlich seltener wie bei meinem Programm. Aber erst die letzten Tage hat mir ein Kunde im Internet etwas zeigen wollen und der IE ist mit diesem Fehler abgestürzt. Sogar gleich mehrmals hintereinander.

Zwischen den verschiedenen PCs auf denen der Fehler bisher vorkam lässt sich Hardwareseitig kein Zusammenhang erkennen. Unterschiedliche Hardware (Verschiedene Hersteller), zwischen Neugerät und max 2 Jahre alt. Alle i7-6x.
Softwareseitig gibt es da schon mehr Gemeinsamkeiten. WIn10 aktuell, viele gleiche Programme im täglichen Einsatz.

Am BIOS und den Treibern habe ich bisher nichts gemacht.

Zum Schluss liegt es am Virenscanner - der ist auch bei allen gleich

[ramses]

Hallo Roland

da hast du ja deinen "Verdächtigen". Jetzt musst du Ihn noch der Tat überführen.

Hast du den Artikel in den Medien gelesen der beschreibt dass Virenscanner Zusatz Programme bereits mehr Probleme als Nutzen bringen und eigentlich darauf verzichtet werden sollte...

https://www.heise.de/security/artikel/E ... 09009.html


Gruss Carlo