CPU Stecken bei 100% auf den Kunden-PC, alle debugging-Vorschläge?

Question

Ich bin mit einem dead-end situation mit einem der clients, die mit meiner software.Der etwa 40 Exemplare unserer verkauften Produkt (Anwendung programmiert .NET 2.0 verwenden VB.NET 2005), über 2 kommen nicht mehr reagiert mit 1-Kern des dual-core-CPUs stecken in 100% (Programm nutzt 1 Kern nur)

Die logische Vermutung ist eine Endlosschleife verursacht dieses Verhalten, aber das sind Tausende von code-Zeilen mit vielen, vielen Schleifen.Das ist alles, die Informationen, die ich habe;nun, wie tun Sie vorschlagen, ich gehe Debuggen dieses Problems?

EDIT:Im Grunde, die software ist verantwortlich für die Berechnung der Höhe des Betrages ausgegeben, mit anderen Geräten, wie PCs, etc.Es ist ein Internetcafe-management-Programm und schlägt intermittierend, d.h.es ist die Subtraktion Kredit, wenn ist nicht.Es hat andere Dinge im hintergrund zu, wie das überprüfen, um zu sehen, wenn es Zeit ist, um eine Datenbanksicherung zu erstellen, unter anderem.

EDIT:Gelöst.Es war höchst unwahrscheinlich problem.Die Access-Datenbank-Engine, die ich verwendet habe, da das DBMS ist eigentlich der Teil meiner Anwendung, der problematisch ist.Es hat Schwierigkeiten beim arbeiten mit einer Zeile-NUR EIN FRIGGIN ZEILE-in einer der Tabellen.Ich kann nicht löschen oder sonst einen Datensatz hinzufügen Bezug auf die Zeile in einer anderen Tabelle;Auch MS Access 2007 bewirkt, dass die CPU auf 100%, wenn ich zu arbeiten versuche, die Zeile!

Ein einfaches "komprimieren und Reparieren" - Befehl gefixt alles.Ich denke, ich werde das Problem, dass der Befehl jedes mal, wenn meine Anwendung startet.Das würde verhindern, dass dies erneut passiert.

Dank WinDbg, die ich finden konnte, wo das problem lag.Ich empfehle jedem, zu lernen, wie es zu benutzen, weil es eine echte Zeitersparnis.

Answer 1

Installieren Sie windbg (Windows debugger) auf dem Zielcomputer.Ruft den debugger, und befestigen Sie die verdächtigen Prozess, führen Sie das Programm und warten Sie dann, bis das problem passiert.Wenn das problem passiert ist, rufen Sie den folgenden Befehl in der debugger-Befehl-Linie

!runaway

Dies wird zeigen, was Ihre Themen sind, verbrauchen die meiste Zeit.Dann erhalten Sie mehrere thread-stacks von diesem thread, dass ist verbraucht die meisten der cpu-Ressourcen.

Hier ist ein Beispiel:

0:015> !runaway

Benutzer-Modus-Zeit Thread-Zeit 0:1074 0 days 0:00:21.637 11:137c 0 days 0:00:02.792 4:12c8 0 days 0:00:00.530 9:1374 0 days 0:00:00.046 15:13d0 0 days 0:00:00.000 14:1204 0 days 0:00:00.000 13:154c 0 days 0:00:00.000 12:144c 0 days 0:00:00.000 10:1378 0 days 0:00:00.000 8:1340 0 days 0:00:00.000 7:12f0 0 days 0:00:00.000 6:12d4 0 days 0:00:00.000 5:12d0 0 days 0:00:00.000 3:12c4 0 days 0:00:00.000 2:12c0 0 days 0:00:00.000 1:12b4 0 days 0:00:00.000

Nehmen wir jetzt an, wir wollen ein call-stack für den zweiten thread in der Liste, Gewinde 11, also wir wechseln Sie zunächst in thread 11.Dies kann durch Eingabe von ~11s.

0:015> ~11s

eax=03fbb270 ebx=ffffffff ecx=00000002 edx=00000060 esi=00000000 edi=00000000 eip=77475e74 esp=0572f60c ebp=0572f67c iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003B echtes gs=0000 efl=00000246 ntdll!KiFastSystemCallRet:77475e74 c3 ret

Jetzt erhalten Sie ein call-stack für diesen thread durch ausführen kp:

0:011> kp
ChildEBP RetAddr  
0572f608 77475620 ntdll!KiFastSystemCallRet
0572f60c 75b09884 ntdll!NtWaitForSingleObject+0xc
0572f67c 75b097f2 kernel32!WaitForSingleObjectEx+0xbe
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Mozilla Firefox 3.1 Beta 1\nspr4.dll - 
0572f690 10019a0b kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
0572f6ac 10015979 nspr4!PR_MD_WAIT_CV+0x8b
0572f6c4 10015763 nspr4!PR_GetPrimordialCPU+0x79
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Mozilla Firefox 3.1 Beta 1\xul.dll - 
0572f6e0 64d44d6a nspr4!PR_Wait+0x33
0572f708 64dbe67e xul!NS_CycleCollectorForget2_P+0x698a
0572f72c 10019b3f xul!gfxWindowsPlatform::FontEnumProc+0xfd4e
0572f734 10015d32 nspr4!PR_MD_UNLOCK+0x1f
0572f738 1001624b nspr4!PR_Unlock+0x22
0572f754 1001838d nspr4!PRP_TryLock+0x4cb
00000000 00000000 nspr4!PR_Now+0x109d

Der Befehl kp wird, drucken Sie die Parameter.Lokale Variablen können gedruckt werden mit dv.

Alternativ können Sie process explorer von sysinternals.

Wenn all dies ist nicht möglich, weil es ein remote-client-Computer, installieren Sie userdump, die erstellt eine dump-Datei, die gesendet werden können, um Sie für die weitere Analyse.Sie können eine batch-Datei erstellen für den Kunden zum aufrufen userdump mit den richtigen Parametern.Userdump ist ein tool von Microsoft, die können heruntergeladen werden von Ihrer web-Seite.

Answer 2

Wenn möglich, bekommen Sie ein dump-Prozess und betrachten Sie die stack-trace.
Ich habe nie, aber es sollte die Arbeit mit VS/WinDbg und SOS (Son of Strike).Hier ist eine blog post über es.

Answer 3

Wenn es ist eine Endlosschleife, dann versuchen Sie das Anhängen eines Debuggers und schlagen, brechen.WinDbg ist für dieses ideal.

Die Technik funktioniert auch für den Fall, wenn die Schleife wird nur Durchlaufen zu viele Male, aber schließlich trägt mit dem rest des Codes.Es ist möglich, verbringen Sie ein paar Minuten, wiederholen Sie das Verfahren, um eine gute Probe.

Diese Technik hat mich gerettet, mehrere Male, und funktioniert gut für nicht reagierende Anwendungen zu :)

Answer 4

Auch Sie müssen, um herauszufinden, wo es tight-looping.Was ist Ihre Kunden zu tun, die mit der software an der Zeit?Was macht die software überhaupt?

Möchten Sie vielleicht zu prüfen, indem eine Menge von logging-code und gibt dem client eine Kopie mit allen, dass die Protokollierung aktiviert ist, Ihnen zu helfen, verfolgen, wo Sie sind, die Probleme haben.

Answer 5

Einen logger zu verwenden wie log4net die Sie einführen können, um Ihre vorhandene Codebasis mit postsharp.Log-all-Methode, ein-und Ausstiege - so sollten Sie die fehlerhafte Methode.Dann können Sie verbessern Sie Ihre Protokollierung, wenn es ist immer noch erforderlich.

Wie es aussieht wird das arbeiten für vb.net auch, obwohl ich keine Erfahrung.Vielleicht in diesem Artikel hilft Euch ein bisschen.

Answer 6

Haben Sie zum interview jene Kunden sehr gründlich.Das ist nicht immer einfach, aber es ist Ihre einzige Schuss auf die Verengung das problem.

Dann vorsichtig die Ablaufverfolgung, und vergessen Sie nicht, zu Erröten an strategischen Punkten (oder set AutoFlush).

Aber es könnte ein subtiles timing-problem, das geht Weg, durch die zusätzliche Verzögerung der Verfolgung...

Answer 7

Es gibt möglicherweise ein problem mit single-core-und multi-core-CPUs anders zu Verhalten, zum Beispiel, wenn im hintergrund ein thread versucht, die Aktualisierung der Benutzeroberfläche.

(Und ich gebe zu, dass ich schrieb eine app zurück in den dunklen Zeiten, die nicht sauber trennen hintergrund und UI-threads und verursacht Probleme beim multi-core-CPUs bekam mainstream.Die Lösung war, rufen Sie die SetProcessAffinity zu beschränken, die app zu einem single-core)

Wenn das der Fall ist, sollten Sie prüfen, ob der 100% CPU nur auftreten, mit eine spezielle Art von CPU, und ob mit SetProcessAffinity löst das problem.Wenn es funktioniert, Sie wissen, wo Sie suchen in Ihrem code.

Answer 8

Könnte es ein threading-problem?"nicht nur zeitweise" macht ich glaube, es.Ist das Programm empfangen Signale/Nachrichten von außen, wie remoting/DCOM/sockets?Ist Fortschritt Informationen in Bezug auf solche Nachrichten vorgestellt, in der Benutzer Schnittstelle?

Einmal habe ich erkannt ein threading-problem, da ich immer ein viel Behauptet.Es war eine sanity-check GELTEND machen, für den Anfang von einer Meldung über XML-RPC werden:

"<?xml " 

und die GELTEND machen, folgte ein überschreiben der Erinnerung an die Botschaft.Von Inspektion es stellte sich heraus, dass aufgrund einer fehlenden Sperre in einem kritischen Abschnitt.Dieser Nachweis war nur möglich, weil das problem war heute so früh von dem BEHAUPTEN (und es passiert ist ausreichend oft, um erkannt zu werden).

Dies ist nicht sehr specfific oder gezielte Beratung, sondern meine Vorschlag dann fügen Sie Behauptet in Orten, die können werden betroffen ist ein threading-problem.

Beachten Sie, dass feuern Behauptet, impliziert nicht unbedingt Abbruch das Programm oder werfen die message-Boxen.Behauptet werden kann Weiterleitung auf eine log-Datei statt, einschließlich der volle Stapel trace zum Zeitpunkt der GELTENDMACHUNG feuern.