Stephanus

Stephanus Schultes Blog, Windows, IE, und was es da sonst noch gibt....

[W7][TIP] %processname% (reagiert nicht)

[W7][TIP] %processname% (reagiert nicht)

  • Comments 7
  • Likes

Jeder kennt das Problem, immer dann wenn man möglichst schnell mal eben [=>Murphy’s Law, nicht zu verwechseln mit Murphy’s Law Zwinkerndes Smiley] noch etwas nachschauen möchte, dann wird man sich manchmal mit folgendem Bild konfrontiert sehen:

image

 

Was bedeutet “reagiert nicht”/”not responding”?

Dazu muss ich ein wenig ausholen:

<techie_erklär_mode>
Ein Prozess ist letztlich nur ein Container, der Ressourcen bereitstellt. Diese Ressourcen können z.B. Speicher, Files, … sein.

In einem Prozess arbeiten sog. “Threads”. Diese – letztlich auch eine Form einer Ressource – leisten die eigentliche Arbeit innerhalb eines Prozesses und nutzen dabei die Ressourcen des eigenen Prozesses [es gibt zwar auch von Prozessen losgelöste Threads, diese sind allerdings eine Sonderform, auf die ich hier nicht eingehe, wer mag kann sich gerne mit Fibern weiterbilden! Zwinkerndes Smiley ], die dem Prozess vom Betriebssystem zur Verfügung gestellt worden ist.

Der sog. Main Thread, oder auch “Thread 0” ist für die Verarbeitung von Window Messages zuständig und nutzt dazu eine Message Queue, in der alle eingehenden Messages zwischengespeichert werden.
Der Main Thread überwacht also die Queue und reagiert auf eingehende Messages. Eine solche Message kann z.B. eine Mausbewegung und/oder Klick sein.
Diese Message Queue hat allerdings eine begrenzte Länge. Wenn also nun der Main Thread blockiert ist – entweder durch einen Live Lock oder einen Dead Lock, wobei meist ein Dead Lock zu finden ist, bei dem der Prozess auf z.B. die Beantwortung eines IO Requests wartet – dann kann diese Message Queue nicht abgearbeitet werden. Wenn nun immer weiter Messages an den Prozess gehen und dadurch irgendwann (was sehr schnell gehen kann) die Message Queue vollgelaufen ist, dann erkennt das Betriebssystem, dass keine weiteren Messages mehr angenommen werden können und reagiert so, dass das Windows ausgegraut wird und in der Titelleiste das “reagiert nicht” angezeigt wird.
</techie_erklär_mode>

Was kann ich gegen einen nicht reagierenden Prozess tun?

Hier habe ich mehrere Möglichkeiten:

  1. Den Prozess mittels Taskmanagers beenden
  2. Einen Debugger an den Prozess attachen und anhand von Symbols & Source die Ursache herausfinden. (dies ist vermutlich das, was am wenigsten häufig durchgeführt wird! Zwinkerndes Smiley Siehe hierzu auch Wait Chain Traversal)
  3. Bei Windows 7 gibt es den sog. “Resource Monitor” (Zum Starten entweder über den Taskmanager->Performance->Ressource Monitor oder über direkten Aufruf “perfmon.exe /res” oder über den Performance Monitor)
    imageimage

    Wenn man nun den Resource Monitor geöffnet hat, so werden nicht reagierende Prozesse in “rot” angezeigt:
    image
    Nun hilft ein beherzter rechts-Klick auf den Prozess und ein weiterer Links-Klick auf “Analyze Wait Chain…”:
    image
    um folgende Information zu erhalten:

    image
    Anhand dieser Information kann man versuchen die Verklemmung zu beseitigen. Hier können u.a. neben dem Warten auf einen bestimmten Prozess auch blockierte Ressourcen (siehe Handles) aufgezeigt werden. Über dies kann dann der eigentliche Verursacher ausgemacht und entsprechende Maßnahmen eingeleitet werden.

P.S.: in den Screenshots ist Powerpoint zu sehen, nicht weil es “anfällig” dafür ist, sondern weil ich heute selber über das Problem gestolpert bin und so ein schnell verfügbares Repro hatte – sprich dies kann mit JEDEM Prozess passieren!

 

Manchmal ist es an der Zeit Platz für Neues zu machen.

Bis zum nächsten Post

 

Stephanus

Comments
  • Ich erzeuge mit adplus oder procdump hang Dumps und schau sie mir mit WinDbg an. WCT findet halt nicht alles.

  • Ja, ist natürlich möglich, siehe 2., denn adplus macht ja auch nichts anderes als einen cmd debugger an den Prozess hängen.

    Letztlich wäre das auch über den "Taskmanager->Process->rechts Klick auf den Prozess->Dump erstellen" möglich, aber das Debuggen ist eher "advanced" und vom Aufwand nicht immer sinnvoll! ;)

    Wichtig dabei ist aber auch immer, dass bei 64bit Maschinen der richtige Debugger genutzt wird, 64bit, wenn es [auch bei 32bit] um die Ressourcen vom OS geht, und bei 32bit Anwendungen den 32bit debugger, wenn es um das eigentliche Programm Debuggen geht und nicht um die Kommunikation mit dem OS! ;)

    -Stephanus

  • WinDbg sagt einem schon welche Version man nehmen soll.

    Btw, hast du meine Frage wegen dem Ie9 connect Eintrag gelesen?

    Gruß

    André

  • ^^wie gesagt, es hängt davon ab, was ich mir anschauen möchte. Es macht ab und an Sinn auch mal den 32er zu nehmen oder andersherum.

    Bsp.: den ("echten") Usercontext einer 32bit App wird man über Taskmanager->Create Dump File nie sehen! ;)

    Auf die Frage antworte ich in dem anderen postkommentaren.

    -Stephanuss

  • da wir gerade beim WinDbg Thema sind. Ich hab ab und zu diese komische Darstellung:

    public.sn2.livefilestore.com/.../WinDbg_6.12.2.633_doubleText.png

    da wird einfach alles doppelt ausgegeben. Kannst du da bitte mal nachfragen, da in der WinDbg google group keiner antwortet? Gibt es irgendwo ein offizielles WinDbg Forum?

  • Hallo Andre,

    (kurz aus dem Urlaub geantwortet:) ich glaube, die Anzahl an windbg Nutzern ist recht überschaubar, von daher kenne ich zumindest keine Grps außerhalb von Microsoft! ;)

    Die Doppelung von Zeilen hab ich meistens dann gesehen, wenn ich keine neue Instanz von Windbg genutzt habe.

    Tritt das immer bei diesem (oder immer bei den gleichen) Dumpfile auf? Oder tritt das nur manchmal auf?

  • Es tritt meistens dann auf wenn ich das Debuggen mit SHIFT+F5 abgebrochen habe und eine neue dmp geöffnet habe. Aber dann auch nicht immer, sondern nur ab und zu. In der Google group hat ein anderer Nutzer das gleiche Problem. Ich habe das Problem mit Version 6.11 (wegen dem !VM Bug in 6.12 noch in Benutzung) und 6.12.

    Noch etwas. Kann man das Akzeptieren der EULA beim Symbol Server anders abspeichern? Wenn man die EULA akzeptiert wird die Datei symsrv.yes angelegt. Bei xperfview (64Bit) klappt das wegen der UAC nicht wenn man das WPT nach C:\Program Files installiert. Schade, dass man sonst nirgends zu WinDbg Fragen stellen kann, die dann von dem Team gelesen wird :'(

    schönen Resturlaub noch

    Gruß

    André

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment