Process StUserStorage.exe has terminated abnormally

    Nachdem ich mich nun schon eine geraume Zeit (ca. 5 Monate)mit dem folgenden Fehler herumschlage, möchte ich doch mal die Dienste dieses Forums nutzen.


    Auf der Serverkonsole unseres Sametime-Servers (gleichzeitig Administrationsserver) erscheint minütlich folgende Fehlermeldung:


    Process C:\Lotus\Domino\StUserStorage.exe (4388/0x1124) has terminated abnormally


    Wir haben ST in Version 8.0.2 installiert, der Notes-Server ist auf Version 7.0.3.


    Fehlerbereinigung nach der Technote 1252974 habe ich schon durchgeführt - ohne Erfolg. Auch das Update der neu signierten Sametime-Applets brachte keine Änderung.
    Der Artikel http://www-10.lotus.com/ldd/st…72db004a0c49?OpenDocument im IBM-Forum trifft zwar den Fehler, jedoch passt die ST.Version nicht - und eine Sametime.ini find ich auch nicht (bin noch ein recht "junger" Notes-Admin).


    Was das Ganze noch (für mich) rätselhafter macht: Der Fehler wandert mit der Zeit zu anderen ST-Modulen. Vor dem letzten Server-Neustart wurde das Modul z. B. STWBServer.exe gemeldet.


    Bin für jeden möglichen Lösungsweg dankbar! Ach ja, auf die Funktion von ST hat der Fehler anschienend keinen Einfluss.

    Sametime.ini findest du im Notes Verzeichnis.


    Wie wäre es einfach mal mit Datei Suche ?


    Hast du den gefunden Artikel und dessen Lösungsvorschläge denn schon ausprobiert, unabhängig davon ob die Version passt.


    Hast du dir die Sametime-Logs schon mal dazu angeschaut bzw die betriebssystem Logs ?

    Danke für den Hinweis auf die Suche ... ;) - ich hatte versehentlich nur das Data-Verzeichnis durchsucht.


    ich habe die INI sowie die beschriebenen Reg-Keys geprüft - sie entsprechend den empohlenen Werten.


    Das Sametime-Log weist keinerlei Fehlermeldungen auf.


    Die Win-Eventlogs (Server 2003 SP 2, 32 Bit) führen den Fehler nicht auf (Application, Security und System, alle Events).
    Das manuelle Stoppen und Starten des Win-Dienstes wird prokolliert.


    Nur im Konsolenlog wird der Fehler dokumentiert.

    Klar hab ich wir das - der Fehler hat die letzten geschätzen 20 Reboots jedoch leider schadlos überstanden. :(


    Das Einzige, was sich (manchmal) nach dem Reboot ändert, ist das als Fehlermeldung angezeigte Sametime-Modul. Wobei sich das auch ohne ersichtlichen Grund im laufenden Betrieb ändern kann.


    Der letzte vollständige Reboot erfolgte am vergangenen Montag. Ursache war ein gemeldetes Problem mit dem Speicher, aufgrund dem die names.nsf nicht mehr administrierbar war (der Server ist auch der Administrationsserver des Adressbuches). Einen Bezug auf den Sametime-Fehler konnte ich jedoch nicht feststellen. :(

    Also die Meldung kommt eigentlich dann, wenn einer der Notes Tasks abstürzt.
    Das muss aber auch im Eventlog des Betriebssystems zu finden sein.
    Wenn es immer wieder ein anderer ist, scheint das aber weniger ein Notes Problem als eher ein generelles Problem auf Systembene zu sein.

    Hab ich auch vermutet, da ja die Task auch alle in als Windows-Dienste administrierbar sind.


    Der normale Start des Dienstes (beim Serverstart) wird auch im Eventlog protokolliert - nur über die angebliche (?) Beendigung des Dienstes bekommt Windows nichts mit.
    Der Dienst (sowie alle anderen ST-Dienste) hat den Status "Running".

    Bei welchem Serverstart ?
    Den von Windows oder den vom Domino ?


    Die Sametimedienste müssen alle auf manuell stehen, da die vom Domino nachgestartet werden und zwar auch in einer definierten Reihenfolge

    Ich meinte den Windows-Serverneustart. Ich starte bei Bedarf in der Regel den ganzen Server neu - da es eine VM ist, geht das recht zügig.


    Die Windows-Dienste haben den Starttyp "manuell" - s. Screenshot

    So, hatte heute wieder die wundersame Fehlerwandlung. Nach einem Neustart erscheint nun die folgende Meldung auf der Console


    Process C:\Lotus\Domino\StResolve.exe (5324/0x14CC) has terminated abnormally


    Auswirkungen auf die ST-Funktion hat der Fehler wie immer nicht ...

    So, wir haben nun dem Server eine zweite CPU verpasst, nachdem dieser doch recht beschäftigt war - der Fehler ist auch vorerst verschwunden.
    Ob das der Grund war, kann ich nicht sagen - aber die Hoffnung stirbt bekanntlich nie ... :hammer: