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 weed,

ich hatte das Problem auch schon zweimal. Die Tipps mit gvkernel.dll umbennen usw. haben immer nichts gebracht, bzw. wieder andere Fehler erzeugt.

Bei mir hat nur eine Überinstallation funktioniert.

Gruß ELDI-Man

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.

Hallo,

es gibt keine konkrete Lösung für das Problem. Es gibt so viele Gründe. Bei dem einen reicht eine Neuinstallation bei dem anderen ein Updates der Treiber vom MB.

Wenn es nocht so häufig ist, dann laß es so laufen!

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 Captain,

ich meine, sonst würde ja auch nicht der Fehlerhinweis auf den Kernel kommen oder? Kann ich mir bei HBCI+ PIN/TAN schlecht vorstellen. Also müsste es sich um Chipkarte handeln.

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 !

Naja,

die Fehlermeldung lautet: "Fehler bei der Kernel-Initialisierung".
Welcher Kernel betroffen ist, steht da nicht (Starfinanz für Chip/Disk oder PPI für PIN/TAN).

Sollte der Eintrag in der uno.ini nicht auf das Sfirm Verzeichnis verweisen, wird dieser direkt beim Start korrigiert. Kann man übrigens auch in den Protokollen als Ereignis sehen...

Was helfen könnte, sofern Chipkarte/Disk im Einsatz ist:
Die Werte für Timeout und Retry leicht nach oben setzen, der Kernel arbeitet offensichtlich wie nen lokaler Proxy und wenn der nicht schnell genug gestartet ist..

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.

HILFE! Du bist zu schnell

Du hast gerade als ich geschrieben habe die inis gepostet. Die sind inhaltlich absolut gleich, die mit Semikolon markierten sind auskommentierte Einträge. Sie so aus als hätte Sfirm mal woanders gelegen (E) und bei der Umstellung auf LW S ist vielelciht Murks entstanden. Wenn du eh drüberinstallierst, kannst du auch gleich vorher das HBCI Unter-Verzeichnis löschen. Wird bei der Installation sauber wiederhergstellt. Aber Datensicherung nicht vergessen..

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

Der executable PAth ist irrelevant!!!!!!!!!!

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

Welche Leser sind das denn?

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.

Ich liste die Geräte jetzt mal nicht *alle* hier , aber euinen guten Querschnitt:

• o- cyberJack e-com (USB)
• o- Towitoko Chipdrive 110 (Seriell, PS/2)
• o- Cherry Tastatur G 80-1501 HAD (mit Reader, PS/2)
• o- Reiner SCT cyberJack (PS/2)