COM ports im Griff bekommen

[r_amse_s]

Hallo,

kann man feststellen, wenn ein COM port offen ist, welche Applikation ihn geöffnet hat und ggf. forciert schliessen, wenn die eigene App ihn braucht ?

thx

[Reinhard Kern]

Zitat:

Zitat von r_amse_s

Hallo,

kann man feststellen, wenn ein COM port offen ist, welche Applikation ihn geöffnet hat und ggf. forciert schliessen, wenn die eigene App ihn braucht ?

thx

Hallo,

Zitat aus einer Applikation, die das kann (für Dateien, dürfte aber für Devices gleich sein):

How does it work ?
OpenedFilesView uses the NtQuerySystemInformation API to enumerate all handles in the system. After filtering non-file handles, it uses a temporary device driver - NirSoftOpenedFilesDriver.sys for reading the information about each handle from the kernel memory. This device driver is automatically unloaded from the system when you exit from OpenedFilesView utility.

Hört sich sehr komplex an, besonders weil ein Kernel-Treiber notwendig ist.

Gruss Reinhard

[QuickAndDirty]

Du bist ein Böser Entwickler wenn du so ein Programm schreibst.
Ich habe auch immer nur oft feststellen können das es nicht gerade einfach ist
herauszufinden welches Programm gerade den Port blockiert und ob überhaupt etwas den Com Port nutzt.

Um das zu prüfen versuche ich in der Regel über das im Windows zubehör Mitgelieferte hyperterminal auf dem
Com port heraus zu wählen. Wenn mir hyperterminal sagt das geht nicht und unsere Software ist aus dann kann ich dem
Kunden auch nur sagen er solle mal feststellen was da den Port blockiert. Das ist zumindest eine Sichere Methode um
nicht den Schwarzen Peter zugeschoben zu bekommen wenn man weiß das es an der eigenen Software nicht liegt.

Meist ist es irgendeine alte Kartenlese oder PDA syncronisierungssoftware die den Port wenn sie einmal läuft in beschlagnimmt
und so ohne weiteres auch nicht wieder frei gibt.


Ich kann mir nicht vorstellen das es Spaß macht einen
Fehler aufzuklären der durch ein Fremdprogramm das kein
Schwein kennt verusacht wird, weil es unsere Software vom Port trennt.

IMHO
du versuchst Malware zu entwickeln.

[WS1976]

Hallo QuickAndDirty,

ich habe bei meinen Tools genau das gleiche Problem. Ich verstehe nicht ganz was schlimm daran sein soll, wenn man feststellt wer die Com offen hält und ( da hab ich aber Bedenken ) diese Verbindung killt.
Ich würde schon alleine für die Kenntnis wer die Com in den Klauen hat einen Luftsprung machen.

Gruss
Rainer

[messie]

Vielleicht kann man das hier brauchen: CancelIoExDazu müßte man das Handle der offenen COM herausfinden, deren Name ist ja bekannt.
Ich könnte eine solche Lösung auch gebrauchen...

Grüße, Messie

[Robert Marquardt]

Schau mal ob die Sysinternal Tools etwas dazu enthalten. Diese gibt es jetzt zum Download bei Microsoft.

[QuickAndDirty]

Zitat:

Zitat von WS1976

Hallo QuickAndDirty,

ich habe bei meinen Tools genau das gleiche Problem. Ich verstehe nicht ganz was schlimm daran sein soll, wenn man feststellt wer die Com offen hält und ( da hab ich aber Bedenken ) diese Verbindung killt.
Ich würde schon alleine für die Kenntnis wer die Com in den Klauen hat einen Luftsprung machen.

Gruss
Rainer

Oh nein, das Herausfinden wer den scheiß verdammten Port blockiert ist, ok.

Aber eine von diesen blöden SuperTopMostWindow Lösungen ist voll daneben!!!!!!

Wenn mein Programm von einem fremden Programm vom Port getrennt wird
oder weil es den Port benutzt von einem anderen Programm beendet wird,
dann ist das kein Spaß.
Sollte ich so einen Fehler jemals aufklären müssen würde der Kunde
von uns sicher eine dicke Rechnung bekommen,
denn das ist kein normaler Support mehr.
Die Rechnung kann er dann ja an den Hersteller der Malware weitergeben.

Zitat:

Zitat von messie

Vielleicht kann man das hier brauchen: CancelIoExDazu müßte man das Handle der offenen COM herausfinden, deren Name ist ja bekannt.
Ich könnte eine solche Lösung auch gebrauchen...

Wofür? Was, wenn 2 Anwendungen sich um Com 1 kloppen? und jede erstmal die ganze Kommunikation killt und sich selbst wieder reinsetzt? Das ist doch Schwachsinn!!!

[ErazerZ]

Ohne Treiber wird das nichts, ist das selbe Prüfverfahren wie bei Dateien nur halt mit Dateiname \\.\COM1\. Selbst Unlocker (Programm zum geöffneten Datei-Handles schließen) benutzt einen Treiber und eine DLL.

[Reinhard Kern]

Zitat:

Zitat von QuickAndDirty

Du bist ein Böser Entwickler wenn du so ein Programm schreibst.
.....
IMHO
du versuchst Malware zu entwickeln.

Hallo?

Ich entwickle garnichts in der Richtung, ich habe nur aus der Beschreibung einer der Utilites zitiert, mit der man offene Dateien feststellen und notfalls auch schliessen kann - das konnte ich übrigens als Server-Admin schon immer und ganz offiziell mit MS-Tools für die Serververwaltung.

Ich werde mich aber wegen deiner falschen Anschuldigungen nicht gleich erschiessen. Jedenfalls noch nicht heute.

Gruss Reinhard

[messie]

Zitat:

Zitat von QuickAndDirty

Zitat:

Zitat von messie

Vielleicht kann man das hier brauchen: CancelIoExDazu müßte man das Handle der offenen COM herausfinden, deren Name ist ja bekannt.
Ich könnte eine solche Lösung auch gebrauchen...

Wofür? Was, wenn 2 Anwendungen sich um Com 1 kloppen? und jede erstmal die ganze Kommunikation killt und sich selbst wieder reinsetzt? Das ist doch Schwachsinn!!!

Das ist der Kampf mit gleichstarken Waffen :mrgreen: - das Prinzip von Erst- und Gegenschlag. Wenn man das nuklear umsetzt freut sich auch der Administrator - endlich mal ein sauberes System.
Aber im Ernst: allein das Feststellen der Anwendung sie sich da reinsetzt wäre schon von Bedeutung. Wir haben Aufzeichnungssysteme gehabt, die standen monatelang im Reinraum rum und haben Daten aufgezeichnet und gefiltert für den Fall, daß es dem Gerät mal schlechter geht. Und dann stellt sich im Problemfall raus, daß irgendein Depp sein Handy dranstöpseln mußte und die serielle Aufzeichnung danach zwei Wochen eine Fehlermeldung angezeigt hat bis es jemand gemerkt hat - keine Daten. Und so etwas bei Kunden wie Micron oder Intel, die pro Stunde Prozessausfall 85000$ (in 2000) angesetzt haben.
Es gibt immer Anwendungen, bei denen Daten kritisch sind, die Entwicklung eines autarken Systems (wo kein Depp etwas zum Reinstecken hat) aber nicht bezahlbar ist.

Grüße, Messie