Häufiger SFirm32-Absturz mit 'Kernel Initialisierung' Fehler

Ein freundliches Hallo in diese Runde,

ich betreue mehrere Firmenarbeitsplätze, arunter auch eingie mit SFirm. Sei einiger Zeit (08/2004) zeigen mehrere Arbeitsplätze ein merkwürdiges Phänomen. Alle Maschienen haben Windows XP/pro, Internet über eine Firewall (ja, Ports sind korrekt konfiguriert und SFirm 32bit: 2.0i
(Online Upd. 2.0i).

Ab und zu tritt beim arbeiten mit den Programm ein Fehler 'Fehler bei der Kernel initialisierung' auf und das Programm schliesst sich. Manchmal direkt nach dem Start, manchmal erst beim abholen der Abzüge. Leider ist das problem nicht reproduzierbar; bei 20 Versuchen tritt es 2 mal auf, aber immer zu einem anderen Zeitpunkt.

Ich habe af den betreffenden Rechner versucht Virenscanner, HP-Tools und was nicht noch so auf einem PC kreucht zu beenden (Taskliste wirklich *sehr* leer). Das Problem tritt immernoch auf. Ich habe mir eine Testmaschiene in einer VMWare installiert (nacktes XP prof und SFirm) und hatte das Problem einmal, danach nie wieder. Kenn jemand dieses Problem oder hat vielleicht sogar eine Lösung?



grüsse ! =)

Hallo,

es gibt die uno.ini im Windows-Verzeichnis. Könnte es eventuell sein, dass mit jeweiligen Installation von z. B. T-Onlineversionen der Kernelpfad auf den jeweiligen Pfad des Programmes gesetzt wird.

Normalerweise sollte dieser immer auf Sfirm32 verweisen.

Ist aber nur eine Vermutung, heisst nicht unbedingt, dass dies zur Lösung des Problemes beiträgt. Obwohl, wenn ELDI-Man beschreibt, dass immer nur eine Neuinstallation geholfen hat, wird ja der Pfad in der uno.ini ja auch immer wieder auf den Sfirm32-Pfad abgeändert.

Das Problem überprüft und behebt die Version I mit jedem Start, zudem kann wenn überhaupt nur das System Chipkarte betroffen sein. PIN/TAN hat nen anderen Kernel, den die uno.ini herzlich wenig interessiert.



Die gvkernel.dll ist der andere Kernel, umbenennen kann nur was bringen wenn wirklich pin/tan im Einsatz ist.

Ich hatte selber mal ein Problem mit der gvkernel.dll, und zwar hatte ich zwei verschiedene auf meinem Rechner. Die aktelle im Sfirm Verzeichnis, eine uralte im Windows Verzeichnis. Die alte wurde natürlich regelmässig benutzt, das Win die Suche nach dll´s in den System Verzeichnissen beginnt.

@Weed:
Welches Verfahren nutzt ihr denn? Chipkarte/Datei oder PIN/TAN?

Hallo,

danke für die Superschnellen Antworten =)

Der gvkernel-tip brachte bei mir (wie bei ELDI) auch keine Linderung. Das SFirm ist eine Netzwerkinstallation und wird per Client mit den gemeinsamen Daten vom Server gestartet (Defaultinstallation, Laufwerk S:).

Die UNO.INI ist mir allerdigns neu. Meine UNO.INI auf einem Rechner mit dem Problem sieht so aus:



Und auf einem anderen Rechner ohne das Problem:



Sooo unterschiedlich sehen die gar nicht aus, aber ich werde mal die INI auf den anderen Rechner kopieren, vielleicht hilft das ja schon . An sich ist die Installation gleich. Sonst werde ich die Arbeitsplätze (das SFirm, nicht Windows auch mal testweise neu installieren.

Wie gehe ich beid er neuinstallation (Netzwerkclient) vor?

Ohh, ganz übersehen:
@Cpt FRAG - in allen Fällen ist das HBCI verfahren mit Chipkarte im Einsatz, mit verschiedenen Lesegeräten (Towitoko/Cherry).



Grüsse !

hi,

oh man, so schnell kann man ja gar net lesen =)

jau, ich versuche das mal auf dem betroffenen PC. Meine INI sieht dann jetzt so aus




Meine %SystemRoot%\System32\gvkernel.dll auf den Maschienen hat die Version 2.3.23.0 (Banking Kernel HBCI C native). Das aber auf allen Clients gleich.

Das wird keine große Linderung sein, aber sind die Treiber des Lesers alle gleich!!!???!??!

Hmm, naja - gleich soweit dieHardware gleich ist
Für die verschiedenen Leser sind verschiedene Systemtreiber installiert (selbstverständlich auch die neuesten stabilen).

Früher nein, heute ja.
wir hatten öfter Proleme mit den pre I Versionen, wenn der Pfad auf ältere T-Online Versionen verwies. Dann hat der ältere T-OnlineKernel bei bestimmten Geschäftsvorfällen bei uns nicht zugelassene (veraltete) Segmentversionen erzeugt.