Dauerhafte Probleme bei 3 Clients

[tttonic]

HI,

wir haben in unserer Umgebung nach einem Hardwaretausch massive Probleme mit 3 Clients.

PANIC: semaphore invalid or not allocated

Build: 7.0.4 (32-bit client)
OS: Windows/XP 5.1 (32-bit) (Build 2600), PlatID=2, Service Pack 3 (4 Processors)
Host Name:

############################################################
### FATAL THREAD 2/8 [ntaskldr:  0d68:  06e4]
### FP=0x03c9f238, PC=0x601767e1, SP=0x03c9eac4
### stkbase=03ca0000, total stksize=262144, used stksize=5436
### EAX=0x010607ac, EBX=0x03c9f430, ECX=0x00930000, EDX=0x00930000
### ESI=0x03c9f0cc, EDI=0x000005dc, CS=0x0000001b, SS=0x00000023
### DS=0x00000023, ES=0x00000023, FS=0x0000003b, GS=0x00000000 Flags=0x00010206
Exception code: c0000005 (ACCESS_VIOLATION)
############################################################
@[ 1] 0x601767e1 nnotes.Panic@4+417 (60b16a43)
@[ 2] 0x60001238 nnotes.OSLockSemInt@8+56 (15c06a1,1)
@[ 3] 0x600011ee nnotes.OSLockSem@4+14 (15c06a1)
@[ 4] 0x60002a08 nnotes.LockHandle@12+296 (2920,3c9f29c,3c9f2a8)
@[ 5] 0x60002846 nnotes.OSLockObject@4+22 (60e23f20)
@[ 6] 0x6001742d nnotes.NameVecCopyhElement@24+61 (2920,0,ff,0,0,0)
@[ 7] 0x60379bc2 nnotes.CopyUI@12+50 (24f7a38,0,3c9f464)
@[ 8] 0x60014563 nnotes.SECKFMUserInfo@12+211 (1,3c9f430,0)
@[ 9] 0x600cccea nnotes.LockScheduleDatabase@12+42 (3c9f598,3c9f7a4,3c9f7a0)
@[10] 0x60702c2d nnotes.JSCheckServerSchedule@12+29 (630f93b4,1643cb1,3c9f7c8)
@[11] 0x630f565f nwrdaemndll.NotesMain@8+479 (0,0)
@[12] 0x004014c1 ntaskldr.EntryFuncWrapper+17 (2bd3514,0)
@[13] 0x60102be0 nnotes.ThreadWrapper@4+208 (0)
 [14] 0x7c80b729 kernel32.GetModuleFileNameA+442 (60102b10)

Da nicht alle 500 Clients das Problem haben (zum Glück!) bin ich etwas ratlos

Was haben wir gemacht:

• cache.ndk, bookmarks.nsf gelöscht
• Maintenance auf den DB (Lokal und Server)
• Notesclient neu installiert
• Names.nsf neu erstellt
• Policy´s für die 3 User rausgenommen
• User aus dem Roaming genommen
• Hardware getauscht

Und nun  habe ich keinen Idee mehr.

gruß
tttonic
[/list]

[hallo.dirk]

@[ 5] 0x60002846 nnotes.OSLockObject@4+22 (60e23f20)
@[ 6] 0x6001742d nnotes.NameVecCopyhElement@24+61 (2920,0,ff,0,0,0)
@[ 7] 0x60379bc2 nnotes.CopyUI@12+50 (24f7a38,0,3c9f464)
@[ 8] 0x60014563 nnotes.SECKFMUserInfo@12+211 (1,3c9f430,0)
@[ 9] 0x600cccea nnotes.LockScheduleDatabase@12+42 (3c9f598,3c9f7a4,3c9f7a0)

Ein verdacht:
Ich würd mal schauen ob die lokale busytime etwas damit zu tun hat....

[tttonic]

@[ 5] 0x60002846 nnotes.OSLockObject@4+22 (60e23f20)
@[ 6] 0x6001742d nnotes.NameVecCopyhElement@24+61 (2920,0,ff,0,0,0)
@[ 7] 0x60379bc2 nnotes.CopyUI@12+50 (24f7a38,0,3c9f464)
@[ 8] 0x60014563 nnotes.SECKFMUserInfo@12+211 (1,3c9f430,0)
@[ 9] 0x600cccea nnotes.LockScheduleDatabase@12+42 (3c9f598,3c9f7a4,3c9f7a0)

Ein verdacht:
Ich würd mal schauen ob die lokale busytime etwas damit zu tun hat....

Die sieht eigentlich völlig normal aus.

[oxyd21]

Wie schaut's mit nem Wartungsvertrag von IBM aus?

[tttonic]

Wie schaut's mit nem Wartungsvertrag von IBM aus?

Das schaut gut aus

Aber machst du immer gleich nen Ticket auf? Ich schau erstmal was wir machen können und ob es das Problem woanders auch auftritt.

[oxyd21]

Klar, weil ich weiss wie lang die Jungs bei IBM brauchen und es für Umme ist bzw. dafür gezahlt wurde.

[tttonic]

Klar, weil ich weiss wie lang die Jungs bei IBM brauchen und es für Umme ist bzw. dafür gezahlt wurde.

Sorry aber wir können jetzt eine Diskussion anfangen wie lange IBM braucht und ob es für Umme ist.  Das ist leider Kontraproduktiv und führt zu nichts.

Aus Erfahrung weiß ich das auch bei IBM es teilweise Wochen dauert bis man eine Lösung bekommt. Zum Glück ist das aber selten.

In der Zwischenzeit kann man ja wohl die Zeit nutzen und mal suchen oder?

Aus der Erfahrung in diesem Forum weiß ich das man meistens bessere und schnellere Hilfe bekommt. Daher brauche ich niemanden der mir erzählt ich soll mich an IBM wenden. Das habe ich bereits in der Vergangenheit gemacht und werde ich auch in der Zukunft machen.
 

[MacSpudik]

Hi tttonic,

ihr habt den Notesclient neu installiert.
Habt Ihr das Data Verzeichnis behalten oder habt ihr auch dieses (bis auf die ID Datei) neu erstellt (nachdem ihr das Roaming deaktiviert habt, versteht sich).

Habt Ihr die Anwender, als das Roaming noch aktiv war, auch mal an einem anderen Rechner anmelden lassen? Kam mit dem gl. Anwender am anderen Rechner auch der Fehler?

Habt Ihr den Anwender mit seiner ID an einem anderen Rechner (ohne Roaming) mal anmelden lassen? Kam da auch der Fehler?

Und last but not least: Was passiert, wenn ein Anwender, der das Problem nicht hat, sich an den betroffenen Rechnern anmeldet. Stürtzt das Notes dann auch ab?

--> Ich vermute auf den ersten Blick ein Problem im Dataverzeichnis der 3 User.

Grüße von
Sebastian

[tttonic]

Hi tttonic,

ihr habt den Notesclient neu installiert.
Habt Ihr das Data Verzeichnis behalten oder habt ihr auch dieses (bis auf die ID Datei) neu erstellt (nachdem ihr das Roaming deaktiviert habt, versteht sich).

Nein wir haben das Data-VZ nicht behalten. Dieses ist frisch erstellt wurden

Habt Ihr die Anwender, als das Roaming noch aktiv war, auch mal an einem anderen Rechner anmelden lassen? Kam mit dem gl. Anwender am anderen Rechner auch der Fehler?

An einem anderem Rechner taucht das Problem nicht auf.  Nur wenn wir einen neuen Rechner neu betanken dann ja

Habt Ihr den Anwender mit seiner ID an einem anderen Rechner (ohne Roaming) mal anmelden lassen? Kam da auch der Fehler?

Das gestaltet sich als schwierig da dieses Notebookuser sind und somit kannst du nicht einem anderen das Gerät tagelang wegnehmen.

Und last but not least: Was passiert, wenn ein Anwender, der das Problem nicht hat, sich an den betroffenen Rechnern anmeldet. Stürtzt das Notes dann auch ab?
Wenn sich ein anderer anmeldet wird Notes aufgrund Multiuser neu konfiguriert. Sonst über ID wechsel schlecht möglich da VIP´s und die lassen ungern mit einer anderen ID in Ihren DB arbeiten.

--> Ich vermute auf den ersten Blick ein Problem im Dataverzeichnis der 3 User.

Wie gesagt. Frisch erstellten Data-VZ

Grüße von
Sebastian

[MacSpudik]

Mhm, bei frisch erstellen Data-Verzeichnissen ....
liegen die Dataverzeichnisse im Windowsprofil der Anwender?
Nutzt Ihr zentrale Schablonen auf den Clients oder liegen die NTFs im Dataverzeichnis?
Wir hatten schonmal das Problem, dass einige NTFs, welche im Windows DefaultUser lagen und ins Windowsprofil neuer Anwender kopiert wurden, defekt waren. Das Problem ist dabei auch selten aufgetreten, weil das Roaming bei bestehenden Anwendern die noch funktionierenden NSF Dateien zur Verfügung stellten. Nur wenn die betroffenen NSF Dateien aus den defekten Schablonen neu erstellt wurden oder Data Verzeichnisse neu erstellt wurden, erschien dann der Fehler.

--> Habt ihr die zentralen Schablonen der Clients (wo auch immer die bei Euch abgelegt sind) mit der Notes Programminstallation auch ausgetauscht oder habt Ihr an Eurem Standard Client in letzter Zeit etwas geändert?

[tttonic]

Mhm, bei frisch erstellen Data-Verzeichnissen ....
liegen die Dataverzeichnisse im Windowsprofil der Anwender?
Nutzt Ihr zentrale Schablonen auf den Clients oder liegen die NTFs im Dataverzeichnis?
Wir hatten schonmal das Problem, dass einige NTFs, welche im Windows DefaultUser lagen und ins Windowsprofil neuer Anwender kopiert wurden, defekt waren. Das Problem ist dabei auch selten aufgetreten, weil das Roaming bei bestehenden Anwendern die noch funktionierenden NSF Dateien zur Verfügung stellten. Nur wenn die betroffenen NSF Dateien aus den defekten Schablonen neu erstellt wurden oder Data Verzeichnisse neu erstellt wurden, erschien dann der Fehler.

--> Habt ihr die zentralen Schablonen der Clients (wo auch immer die bei Euch abgelegt sind) mit der Notes Programminstallation auch ausgetauscht oder habt Ihr an Eurem Standard Client in letzter Zeit etwas geändert?

Die Schablonen liegen zentral. Auf die Idee bin ich noch nicht gekommen. Ich werde die mal austauschen und dann schauen. Villeicht war das ja der Wink mit dem Zaunpfahl..

Danke ich melde mich danach

[koehlerbv]

"tttonic", könntest Du bitte das korrekte Zitieren mit den Mitteln dieses Forums einstudieren? Das ist wirklich nicht schwer!

Angesichts des NSDs würde ich als erstes einen Blick auf die Replikation von lokal und den Update der FTIs richten (als erstes: Abschalten).
Wenn im lokalen (!) DataDir natürlich alles vorher in die Tonne gekippt wurde, entfällt die Sinnhaftigkeit meines Vorschlags.

Bernhard

[tttonic]

"tttonic", könntest Du bitte das korrekte Zitieren mit den Mitteln dieses Forums einstudieren? Das ist wirklich nicht schwer!

Angesichts des NSDs würde ich als erstes einen Blick auf die Replikation von lokal und den Update der FTIs richten (als erstes: Abschalten).
Wenn im lokalen (!) DataDir natürlich alles vorher in die Tonne gekippt wurde, entfällt die Sinnhaftigkeit meines Vorschlags.

Bernhard

Ja kann ich. Habe ausversehen ins Zitat geklickt. Sorry dafür.

Ja wir haben alles vorher in die Tonne gekloppt.

Bin mal gespannt was IBM dazu sagt. Ticket ist ja offen. Ich melde mich sobald ich was genaueres weis

[gribbler]

Hallo miteinander seit kurzer Zeit hab ich ach bei einigen Clients das Problem mit der Meldung semaphore invalid or not allocated.

Ich wollt jetzt mal wissen ob es neue Erkenntnisse gibt.

[m3]

PMR aufmachen, NSD einliefern, ... warten ...

[gribbler]

Sorry, ich verstehe grad nur Bahnhof...

[m3]

Wenn Du bei einem Client Probleme hast, machst Du einen PMR bei IBM auf, schickst Ihnen die NSDs, die bei den Abstürzen entstanden sind und wartest, bis Sie dir sagen, was Du tun sollst.

[Micha B]

Aber nur, wenn sie auch einen Wartungsvertrag für V7 haben 

[m3]

Ahhhhh. Man sollte auch auf den Bereich achten.
Ja, da schauts schlecht aus, Support ist gut, aber aus. 

Upgraden auf 8.5.2. Fp3 und wenn das Problem noch immer auftritt ... siehe oben.

[Micha B]

Oder er/sie/es probiert es mal damit: http://www.ibm.com/support/docview.wss?uid=swg21272213