VC++: Threads und Prozesse "beobachten"

[Alexander I. (daedalus)]

Hallo,

ich habe eine mittlerweile doch recht komplexe VC++ Anwendung, die 
mehrere Workerthreads nutzt, die sich gegenseitig benötigen. Mit der 
Zeit hat sich irgendwo ein richtig fieser Bug eingeschlichen, den ich 
aber nicht gleich bemerkt habe. Die Frage ist nur WO! Der Bug ist nicht 
provozierbar und tritt irgendwann mal auf. Sowohl beim Debuggen der 
Anwendung, als auch beim fertigen Release. Mal alle 10 Minuten, mal nur 
einmal die Woche. Er äußert sich so, dass der PC komplett ausgelastet 
wird, wenn man z.B. einen Breakpoint erreicht, oder die Software mal vom 
Debugger aus "abschießt" (STOP-Button drückt). Manchmal passiert das 
auch "einfach so" während dem Programmfluss ohne erkennbares Zutun. 
Irgendwas ist hier im Thread-Handling nicht sauber und verklemmt sich 
saumäßig, ich vermute irgendeine Endlosschleife, da die Prozessorlast 
auf 100% steigt trotz Dual-Core ;-)

Das Problem ist nur:
Wenn der Bug aufgetreten ist, ist es auch schon zu spät, denn der PC ist 
dann nicht mehr bedienbar, allein der Task-Manager braucht 10 Minuten um 
angezeigt zu werden. Allerdings ist Software die schon offen ist, noch 
einigermaßen bedienbar (außer Visual Studio selbst!).

Jetzt meine Frage:
Gibt es ein Tool, das Prozesse überwacht und anzeigt was die so an 
Ressourcen (Speicher, CPU) verbrauchen, sowie deren Threads anzeigen und 
welche davon wieviel CPU-Zeit benötigen oder was die grade machen 
(SUSPENDED, READY, RUNNING, etc.)? Vielleicht würde ich so eher auf die 
Schliche kommen, was hier faul ist. Kennt ihr da was?

[Peter (Gast)]

wenn die CPU so ausgelastet ist, dann muss es ja eine sehr kleine 
Schleife sein in welcher sich die Threads befinden. Da sollte doch zu 
finden sein. Wenn man im Debugger auf Pause drückt, dann halte doch alle 
Threads an, da kann man doch nachschauen wo sie sind.

Wenn du eine MultiCore CPU hast, dann kannst du der Anwendung nur eine 
CPU zuweisen, damit hast du die andere(n) zum Debuggen frei.

[Stefan B. (stefan)]

Solche Tools gibt es z.B. ProcMon
http://technet.microsoft.com/de-de/sysinternals/bb896645.aspx

Schlauer wäre es eine Überwachung und Debugausgabe in dein Programm zu 
pflanzen, die du z.B. über Debugview anzeigen und aufzeichnen und 
auswerten kannst 
(http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx)

Noch schlauer wäre es den Quellcode bzw. das Programm selbst unter die 
Lupe zu nehmen z.B. mit einem Threads Checker (Intel: 
http://software.intel.com/en-us/intel-thread-checker/) oder Memory 
Checker (http://en.wikipedia.org/wiki/BoundsChecker)

[Arc N. (arc)]

Peter schrieb:
> Wenn du eine MultiCore CPU hast, dann kannst du der Anwendung nur eine
> CPU zuweisen, damit hast du die andere(n) zum Debuggen frei.

Und u.U. eine fehlerfrei laufende Anwendung...

Anderes empfehlenswertes Tool:
http://research.microsoft.com/en-us/projects/chess/
http://research.microsoft.com/en-us/projects/chess/doc.aspx

Ansonsten könnte man auch noch mit Hilfe der Performance Counter, die 
entsprechenden Threads überwachen.

[Alexander I. (daedalus)]

Eine verdächtige while-Schleife hab ich schonmal gefunden, aber ob es 
die war, kann ich erst in ein paar Tagen sagen, denn nichts genaues weiß 
man ja nich ... :)

Vielen Dank schonmal für die Links, die werde ich mir morgen im Büro mal 
ansehen, vom Namen her klingen die aber schonmal vielversprechend!

Wie kann man denn im Visual Studio einstellen, dass der ausgeführte Code 
nur auf einem Core läuft? Ich habe da in den Projekteinstellungen nichts 
finden können? Oder gibt es da ganz allgemeine Tools, wo man in den 
Windows-Scheduler diesbezüglich eingreifen kann?

[Peter (Gast)]

einfach ein Taskmanager auf dem Prozess gehen und Rechte maustaste -> 
Zugehörigkeit festlegen

[Alexander I. (daedalus)]

Tja, da hat wohl jemand den Wald vor lauter Bäumen nicht gesehen. Danke!

[Arc N. (arc)]

Peter schrieb:
> einfach ein Taskmanager auf dem Prozess gehen und Rechte maustaste ->
> Zugehörigkeit festlegen

oder über die Kommandozeile:
start /affinity x

[Alexander I. (daedalus)]

Vielen Dank für die Tool-Tipps. Ich hab mir noch ein paar andere 
SysInternals angesehen und einen Bug tatsächlich gefunden:

Die RS232 wird von einem Thread bedient und es gab eine kurze 
Codepassage, die nicht gesichert war. Genau dort hat irgendein anderes 
Programm auf meinem PC (dem ich das inzwischen verboten habe) sich 
diesen RS232-Port geschnappt und damit durch eine ungeschickte 
while-Bedingung ne Endlosschleife in dem Thread provoziert.