Wie überprüft man COM-Objekte aus Visual Basic-Dump-Datei?

Question

Hintergrund

Wir haben eine Anwendung .NET WinForms in C# geschrieben, die über eine Konsolenanwendung ein Handheld-Speicher Scanner-Schnittstellen zu. Die Konsolenanwendung ist in gutem alten VB6 geschrieben - kein verwalteter Code dort. Die VB6-Anwendung besteht aus mehreren COM-Objekten.

Die .NET WinForms-Anwendung aktualisiert die Daten im Scanner, indem die Konsolenanwendung mit den richtigen Parametern aufgerufen wird. Wenn die Konsolenanwendung gestartet wird, wird ein modales Formular angezeigt, das den Benutzer daran erinnert, das Handheld-Gerät in die Dockingstation zu stellen.

Problem

Ein Kunde hat eine bizarre Situation, in der der Aufruf der Konsolenanwendung zu starten scheint zu hängen, bevor es die Erinnerung Form zeigt. Wenn der Benutzer eine beliebige Taste drückt - selbst etwas Unschuldiges wie Umschalt oder Alt - löst die Anwendung auf und das Erinnerungsformular erscheint. Während es hängt, ist die CPU-Auslastung der Konsolenanwendung sehr hoch.

Wir haben einen Speicherauszug von der Befehlszeilenanwendung mit erhalten. Ich habe einige Erfahrung, verwaltete Dump-Dateien zu debuggen, aber dieser VB 6-Dump ist mir fremd.

Wir haben mehrere vollständige Speicherauszüge in einer Reihe erfasst. In einigen von ihnen scheint es COM-Kleberstapel zu geben. Zum Beispiel zeigen mehrere Dumpdateien ein Call-Stack wie folgt aus:

msvbm60!BASIC_DISPINTERFACE_GetTICount 
msvbm60!_vbaStrToAnsi 
msvbm60!IIDIVbaHost 
msvbm60!rtcDoEvents 
msvbm60!IIDIVbaHost 
msvbm60!BASICCLASS_QueryInterface 
[our code which I think is trying to create and invoke a COM object] 

Es hilft nicht, dass die einzigen Symbole Ich habe von unseren Code sind. Der Microsoft-Symbol-Server hat keine PDB-Datei für msvbm60.dll (oder zumindest nicht von ihrer Version, die 6.0.98.2 ist).

Fragen

ich zu ahnen, kann es einige COM Threading-Problem sein, die nur auf ihrem System geschieht.

1) Wie kann ich den Thread-Status jedes Threads in einer Dump-Datei ermitteln? Wenn dies eine verwaltete Speicherabbilddatei wäre, würde ich !threads und dann !threadstate betrachten, um die Thread-Zustände herauszufinden. Es gibt keinen verwalteten Code, daher kann ich die sos.dll nicht verwenden. Ich habe keine Hinweise mit ~ und !teb gesehen.

2) Gibt es eine Möglichkeit zu sehen, welche COM-Objekte in einer Dump-Datei erstellt wurden? In einem verwalteten Speicherabbild kann ich wiederum eine !dumpheap erstellen, um eine Liste der verwalteten Objekte abzurufen. Gibt es etwas Ähnliches, das ich für COM-Objekte finden kann?

3) Kann ich das Threading-Modell von COM-Objekten in der Dump-Datei ermitteln?

Answer 1

Ich kann nur Frage 1 beantworten. Verwenden Sie !runaway, um den Thread oder die Threads zu finden, die die CPU verbrauchen. Verwenden Sie ~*kb1000, um alle Thread-Stapel zu erhalten.

Answer 2

Sie können Thread-Zustand Dump durch Befehl:

~* 

wird dies nicht als Staat ‚Hintergrund‘ angezeigt werden, werden Sie nur sehen zu laufen, gefroren oder suspendiert.

Ich bin nicht sicher, wie Sie Informationen von COM-Objekten zu bekommen, habe ich nie versucht, aber werde untersuchen, und zurück zu Ihnen, Bezug auf Threading-Modell bekommen, wird es schwierig sein, zu folgern, dass ohne schmerzhafte Überwachung der Anwendung Zustandes nach Schritt durch und sogar mit dem, wenn Sie durch alle anderen Threads durchlaufen werden, es sei denn, Sie verwenden .bpsync 1, die alle Threads mit dem aktuellen synchronisiert, aber das könnte einen Hang verursachen (z. B. gui Thread wurde jetzt einfrieren), so denke ich es wird schwierig sein, wenn Sie nicht auf den Quellcode zugreifen können.