Nein, dies ist keine Geschichte, wie sich meine Festplatte zu schnell dreht und dann das Handle runtergefallen ist


Folgendes: Meine Anwendung lässt sich durch Plugins (DLLs von uns sowie Dritten) zusammenbauen. Nehmen wir an, ein Plugin öffnet den ComPort und hat ihn ganz für sich alleine. Stürzt das Plugin nun ab, stehe ich dumm da: Ich kann das Plugin zwar so gut wie möglich abräumen und neu einladen, aber der Port ist immer noch offen.

Dass ich den Port nur wieder freibekomme, wenn ich den gesamten Prozess (also den Kern und alle anderen Plugins ebenso) abschieße, ist wahrscheinlich allgemein bekannt. Das geht mir allerdings zu weit. Der Port ist unter dem Namen meines Prozesses aufgemacht worden, ich habe nur das Handle verlegt. Ich möchte es nun wiederfinden. Wie?

Ich weiß, dass es nicht wirklich möglich ist, anderen Prozessen die Ports zu schließen. Aber mir selbst?

Im Endeffekt brauche ich nur etwas, das mir das Handle wiederbringt. Bitte sagt mir, dass das irgendwie geht

Ich nehme an, das Plugin (die DLL, die den Port öffnet) gibt das Handle nicht an die Anwendung weiter? Das wäre zu einfach ... (Ich würde das Problem bei Stackoverflow einstellen, dort findet man relativ schnell WinAPI Experten.)

Ja, das ginge wahrscheinlich auch, im Endeffekt ist es ja ein- und derselbe Prozess. Was mir bislang eingefallen ist:

• Den Port ohne Handle schließen bzw. resetten
• Das Handle irgendwie wiederfinden
• Das Plugin übergibt das Handle sicherheitshalber noch einmal an den Kern
• Das Plugin bittet den Kern, die Verbindung zu erstellen und bekommt das Handle
• Eigenen Treiber entwickeln
• Seriellen Port de- und wieder aktivieren

Dass die Plugins wieder über jeden Kram Rücksprache mit dem Hauptprogramm halten sollen ist mir allerdings sehr unsympathisch. Heute sind es noch serielle Ports, morgen TCP-Verbindungen und übermorgen sonstwas. Ich möchte im Kern nicht für alles Sonderbehandlungen und entsprechende Methoden bereitstellen müssen...

Du könntest halt für jedes Plugin einen eigenen Prozess starten. So macht es auch Google Chrome - falls ein Plugin abstürzt, kommt lediglich eine Meldung und Browser kann weitermachen.

In deinem fall sollte damit auch das Handle freigegeben werden. Hat auch den Vorteil: Du brauchst gar nicht wissen, was das Plugin jetzt geöffnet hat. Vielleicht hat es ja einen COM Port und eine TCP Verbindung, wenn du jetzt nur das eine Handle wieder findest, bleibt das andere offen...

Für jedes Plugin ein eigener Prozess ist denke ich auch die beste Lösung.

Das Handle zu finden, ist die eine Sache, aber dafür müsstest du auch wissen was das Plugin alles geöffnet hat, sonst schießt du vielleicht dem falschen Plugin etwas ab. Besser wäre da, wenn das Plugin alle diese Handles direkt an dich zurückliefert. Mit CloseHandle solltest du die schließen können. Als Alternative kannst du auch eine Pluginfunktion schreiben, die das Abräumen basierend auf diesen Daten erledigen muss, sprich du lädst das Plugin wieder und bittest es dann die letzte Instanz anhand dieser Daten (die du ja noch hast) aufzuräumen.

Ganz genau!

Dem Kern irgendetwas von Handles zu erzählen scheitert schon daran, wenn ich bsp. Dinge habe die das ganze komplett in Objekten kapseln und ich nichtmal an das Handle drankomme.

Die Plugins nicht einfach ins Hauptprogramm zu schrauben (bislang hatte ich sie optional als eigene Threads laufen) reicht einfach nicht - Wenn Windows sich schon so schön darum kümmert, die Handles wieder freizugeben wenn der Prozess endet ist ein eigener Prozess eigentlich genau das richtige.

Insgesamt macht das die ganze Geschichte sicher nicht einfacher, aber ich habe auch das Gefühl, dass die Realisierung als Kindprozess einfach richtig ist


Vielen Dank für die Antworten!

Du kannst per NtQuerySystemInformation sämtliche geöffneten Handles eines Prozesses enumerieren. Zusätzlich gibt es dann Informationen, um welche Art von Handle (Datei, Prozess, Thread, etc.) es sich handelt. Danach obliegt es allerdings dir, wie du das Handle eindeutig identifizierst. Bei Dateien ist es relativ einfach den Dateinamen per Handle zu ermitteln. Ich weiß allerdings grade nicht, ob die COM Ports auf top level ebenfalls (in der Art von Pipes) als "Datei" klassifiziert sind.

Edit:
http://forum.sysinternals.com/howto-...opic18892.html

<OT>

Mir fehlen gerade die Worte, wonach müsste ich suchen,um ein Beispiel zu finden, wie man Kind-Prozesse erzeugt und die darin erstellten Formulare einfängt und wie eben Google Chrome im Hauptprozess in Tabs darstellt (oder wo auch immer)

</OT>

Hallo -

Die Handle.exe von SysInternals habe ich vorhin kurz ausprobiert, allerdings hat es mir das Handles auf den ComPort nicht aufgelistet, deswegen habe ich da nicht weiter nachgebohrt.

Momentan befinde ich mich auf einem wilden Ritt durch die Welt der IPC und Jobs unter Windows, ich denke, das ist der richtige Weg.