Forums Neueste Beiträge
 

VB6-Service schlägt fehl....

09/08/2011 - 14:35 von Dieter Strassner | Report spam
Hallo VB'ler

seit Jahren habe ich einen Windows-Service bei mehreren Kunden laufen.

Bei zwei Kunden macht dieser Service schon seit einigen Monaten sporadisch
Probleme, indem er "stecken bleibt". Soll heißen, Windows Protokoll aus
"heiterem" Himmel einen Fehler im Eventprotokoll:

Quelle: Applikation Error
Kategorie: 100 Typ: Fehler Ereignis: 1000
Benutzer: Nicht zutreffend

Beschreibung:
Fehlgeschlagene Anwendung SEMINAR-WdVl-Service.exe, Version 1.5.27,
fehlgeschlagenes Modul msvbvm60.dll, Version 6.0.97.82, Fehleradresse
0x00020566.

Weitere Informationen.

Info: Der komplette Service besteht aus einer kleinen EXE (der eigentliche
Dienst) und einer DLL die nachgeladen wird und in der der Funktionsumfang
steckt. Dort vermute ich deshalb auch den eigentlichen Absturz. Das Programm
macht periodisch Zugriffe per ADO auf den SQL-Server. TimeOuts (z.B. wg. der
Datensicherung o.à. werden abgehandelt), sonstige Fehler protokolliert. In
jeder Funktion/Sub steckt eine Fehlerbehandlung mit Eintrag ins EventLog,
bzw. in applikationseigene Logbuch.

Logs haben mich hier allerdings noch nicht so recht weitergebracht
(...werden entweder riesig groß, würde ich jeden kleinen Schritt über Wochen
protokollieren oder sie haben keine Aussagekraft, da zu "löchrig").

Was kann ich für Informationen aus der Fehleradresse noch erhalten? Und wie?
Oder wie würdet Ihr an die Fehlersuche rangehen?

Viele Grüße - Dieter

EDV-Kommunikation Strassner e.K.
68623 Lampertheim
Internet: www.strassner.biz
 

Lesen sie die antworten

#1 Schmidt
09/08/2011 - 16:57 | Warnen spam
Am 09.08.2011 14:35, schrieb Dieter Strassner:

Beschreibung:
Fehlgeschlagene Anwendung SEMINAR-WdVl-Service.exe, Version 1.5.27,
fehlgeschlagenes Modul msvbvm60.dll, Version 6.0.97.82, Fehleradresse
0x00020566.

Weitere Informationen.

Info: Der komplette Service besteht aus einer kleinen EXE (der
eigentliche Dienst) und einer DLL die nachgeladen wird und in der der
Funktionsumfang steckt. Dort vermute ich deshalb auch den eigentlichen
Absturz. Das Programm macht periodisch Zugriffe per ADO auf den
SQL-Server. TimeOuts (z.B. wg. der Datensicherung o.à. werden
abgehandelt), sonstige Fehler protokolliert. In jeder Funktion/Sub
steckt eine Fehlerbehandlung mit Eintrag ins EventLog, bzw. in
applikationseigene Logbuch.

Logs haben mich hier allerdings noch nicht so recht weitergebracht
(...werden entweder riesig groß, würde ich jeden kleinen Schritt über
Wochen protokollieren oder sie haben keine Aussagekraft, da zu "löchrig").



Direkt aus der Fehleradresse làsst sich meist wenig
ableiten.
Und das "attachen" eines "richtigen Debuggers" wird
wahrscheinlich auch nicht gerade hilfreich (oder machbar)
sein, wenn der Fehler nur "alle paar Wochen" auftritt.

Was Du machen könntest (im Falle Deine Log-Funktionalitàt
ist derzeit auf "Minimum-Output" gestellt - oder gar
ganz ausgeschaltet)...
dann vielleicht eher auf "volle Informationsfülle" schalten -
aber den Log-Mechanismus vielleicht so anpassen, dass
immer nur die LogFiles der letzten 10Minuten oder so
übrig gelassen werden von einer zyklischen "alte LogFiles
löschen"-Routine.

Dann schauen, mit welchem TimeStamp der Ausfall-Eintrag
ins System-Eventlog gemacht wird - und die letzten
Aktionen vor dem AUsfall in Deinen LogFiles zeitlich
korrelliert rückverfolgen.

Vielleicht kann man daraus dann schließen, welche
konkrete Aktion in Deinen-Routinen dann möglicherweise
"tödlich" war.

Ansonsten vielleicht auch den Memory- oder Handle-
Verbrauch mitloggen (des ServiceProcesses).
Vielleicht "leakt" ja eine Deiner Funktionalitàten -
z.B. durch vergessenes ADORs.Close oder - ADOConn.Close -
(oder auch andere "Aufràumroutinen", falls Du
weitere System-Objekte - vielleicht CDO-Mailservices
oder was weiss ich - intern verwendest).

Was vielleicht auch noch sein kann - der Service-
Control(ler) Mechanismus möchte eigentlich immer
recht schnell bedient werden hinsichtlich der
Reaktionen Deiner kleinen Service.exe auf die
einkommenden Info- bzw. State-Requests die der
WIndows-ServiceControl-Mechanismus an Deinen
Service sendet.
Wenn Deine Service.exe aber gerade "abgetaucht ist"
(z.B. in einen einzelnen, eine "kleine Ewigkeit"
dauernden Backup-Call) - dann werden diese
ServiceController-Requests nicht schnell genug
beantwortet - und der ServiceControl-Manager
entscheidet dann womöglich, dass der Service hàngt.

Also, falls Du die Möglichkeit hast, die von Dir
(in der Service-Dll) getriggerten Aktionen möglichst
"granular" zu gestalten (mit was weiss ich, maximal
2-3sek "Abtauch-Dauer"), dann bringt das vielleicht
auch Besserung.
Oder diese lang andauernden Aktionen in Deiner
Dll besser in einem eigenen Thread laufen lassen.
Mit *der* Änderung würde ich aber bis zuletzt warten -
da der Service ja offenbar nur in wenigen Fàllen
dieses Verhalten zeigt und ansonsten gut funktioniert.

Vielleicht auch mal checken, ob die Server-Maschinen wo
das auftritt, vielleicht "besonders dicke" Datenbanken
haben - was Deine (Service-)Routinen dann vielleicht in
besonders lang laufende "TimeOuts" zwingt.

Olaf

Ähnliche fragen