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

[Robert Marquardt]

Deppen haben ueblicherweise immer was zum Reinstecken. :-)

[messie]

angesichts der Ergebnislage gehört dieser thread sowieso in Klatsch und Trasch verschoben...

[Robert Marquardt]

Wie waer es mal nach den SysInternal Tools zu suchen wie vorgeschlagen?

[WS1976]

Hallo Robert,

Sysinternals bringt uns keinen Schritt weiter. Wie willst du die Tools in deinem eigenen prog verwenden? Wir haben uns da schwindlig gesucht und nichts gefunden.
Ich meine ich habe irgendwo ein Stück Code mit dem man ( ohne try and error ) feststellen kann ob die com offen ist oder nicht.
Ich suche danach. Wenn ich fündig werde stell ich das hier ein.

Grüsse
Rainer

[ErazerZ]

Zitat:

Zitat von WS1976

Hallo Robert,

Sysinternals bringt uns keinen Schritt weiter. Wie willst du die Tools in deinem eigenen prog verwenden? Wir haben uns da schwindlig gesucht und nichts gefunden.
Ich meine ich habe irgendwo ein Stück Code mit dem man ( ohne try and error ) feststellen kann ob die com offen ist oder nicht.
Ich suche danach. Wenn ich fündig werde stell ich das hier ein.

Grüsse
Rainer

Naja das ist ganz einfach, zum Beispiel:

Delphi-Quellcode:

{
  Result: Wenn benutzt wird dann True, sonst False.
}
function IsComOpen(wPort: Word): Boolean;
var
  hCom: THandle;
const
  lpszPort  = '\\.\COM%d\';
begin
  Result := True;
  hCom := CreateFile(PChar(Format(lpszPort, [wPort])), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0);
  if (hCom <> INVALID_HANDLE_VALUE) then
  begin
    Result := not CloseHandle(hCom);
  end;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  if IsComOpen(1) then
    ShowMessage('Wird benutzt')
  else
    ShowMessage('Geht scho!');
end;

[WS1976]

Hallo,

das ist genau die Methode, die ich mit "try and error" beschrieben habe.
Ich mache den Port auf und wieder zu, wenns schief geht hab ich halt Pech gehabt.
Das ist so keine akzeptable Lösung. Ich will ohne Öffnungsversuch festellen was mit der
Schnittstelle los ist.
Was macht ich wenn sie besetzt ist booten?

Grüsse
Rainer

[Robert Marquardt]

Das ist genau die Stelle an der dein Programm sich bescheiden muss. Wenn die Schnittstelle in Benutzung ist, dann ist sie eben in Benutzung. Du beschreibst das softwaretechnische Aequivalent von Arroganz.

[WS1976]

Hallo Robert,

das sehe ich nicht so. Was ist denn illegal (oder arrogant) daran wenn man nach einer etwas eleganteren Methode, zum feststellen ob der Port belegt ist oder nicht, sucht.
Ich weiss dass das geht ( habs schon gemacht kanns aber im Moment nicht finden )

Zum Hintergrund:
Wir stellen professionelle Tools zur Zählerauslesung oder zur Parametrierung anderer Geräte her.
Da die Kommunikation noch sehr oft direkt über RS232 oder über virtuelle Com Ports läuft ist dieses Problem für uns existentiell wichtig.
Wer auch immer einen Com Port blockiert, es hilft nur noch ein völliges Ausschalten des Systems.

Ich finde es überhaupt nicht arrogant festzustellen wer die Schnittstelle im Griff und diese Verbindung, natürlich auf Nachfrage, zu killen.

Grüsse
Rainer

[Robert Marquardt]

Es genuegt dann aber festzustellen welches Programm die Schnittstelle belegt und dieses per Hand zu beenden oder zu deinstallieren.
Das Problem auf die harte Art zu loesen, indem man das andere Programm killt (oder zumindest die Verbindung) ist eben "Arroganz". Das eigene Programm ist wichtiger als das andere.
Es liegt natuerlich ein Fehler vor wenn ein Programm einen COM Port blockiert, obwohl nicht das Geraet dranhaengt mit dem man reden will.

[messie]

Zitat:

Zitat von Robert Marquardt

Es genuegt dann aber festzustellen welches Programm die Schnittstelle belegt und dieses per Hand zu beenden oder zu deinstallieren.

Dafür hatten wir jetzt aber noch keine Lösung, die sich in ein Delphi-Programm einbinden läßt. Und damit ist auch keine Überwachung einer Schnittstelle möglich, die z.B. rechtzeitig den Zustand meldet, so daß man das Problem ohne Keule beheben kann.

Zitat:

Zitat von Robert Marquardt

Das Problem auf die harte Art zu loesen, indem man das andere Programm killt (oder zumindest die Verbindung) ist eben "Arroganz". Das eigene Programm ist wichtiger als das andere.

Wichtig ist, daß das System korrekt funktioniert, die Software (egal welche) ist dem untergeordnet. Technik kennt keine Arroganz.

Grüße, Messie

[Robert Marquardt]

Eine einbindbare Loesung ist ja garnicht erstrebenswert. Wenn zwei Programme sich um eine Schnittstelle streiten, dann ist das System falsch konfiguriert. Das laesst sich nicht dadurch loesen das ein Programm dem anderen die Schnittstelle entreisst. Danach ist das System naemlich in einem Fehlerzustand. Das unterlegene Programm funktioniert ja nicht mehr.

[v2afrank]

Ich fände es auch gut, wenn das Programm melden würde , welches Programm die Schnittstelle belegt.
Rausfinden kann man es mit dem ProcessExplorer von Sysinternals. Geht man dort auf Find/Find handle und sucht nach Device\Serial0 zeigt das Programm die Anwendung an, die Com1 benutzt.

Interessant wäre es natürlich diese Funktion in ein eigenes Programm einzubauen

[QuickAndDirty]

Ja man kann anzeigen welches Programm die Schnittstelle benutzt und empfehlen dieses zu beenden, von mir aus mit blitzendem Screen und Warnsirene die Schnittstellenbelegung per Dienst überwachen.

Sollte ich allerdings irgendwann mal auf eine Software treffen die unser Programm automatisch von einer Schnittstelle trennt,
wird das nächste Update diese Funktionalität ebenfalls aufweisen und zusätzlich programme, die auf der "fälschlicher weise"
belegten Schnittstelle liefen, beenden.

Es kann ja nicht sein das Jemand einfach unsere Betriebdatenerfassung nuked.
Zumindest will ich nicht der jenige sein der den Startschuss zum Wettrüsten gibt.


Ich bin eigentlich der Meinung das ein Produkt das Programme von Schnittstellen
trennt um seinen eigenen Betrieb sicherzustellen Malware ist. Denn was bringts, wenn die
achso wichtige Messdatensoftware einwandfrei läuft, aber die Betriebsdatenerfassung deswegen
aus unerklärlichen Gründen streikt?

Du kannst das Problem das in der Stuhl-Tastatur-Schnittstelle liegt nicht auf diese Weise beheben.
Man könnte es arrogant nennen, aber ich bin kein so freundlicher Mensch wie Marquart , für mich ist das
Schwachsinn, sehr teurer Schwachsinn.

[WS1976]

Hallo Robert,

natürlich ist es erstrebenswert eine eingebaute Lösung zu haben.
Aber nur für den Teil der die Anwendung ermittelt die die Com belegt.
Für das automatische Abschiessen geb ich dir Recht!

Gruss Rainer

[QuickAndDirty]

Dann sind wir ja einer Meinung.
Hoffen wir das der Threadsteller sich überzeugen läst.

[Robert Marquardt]

Ich habe mir die SysInternal Tools nochmal angeschaut und da steht etwas von Treiber fuer ProcessExplorer. Ich glaube das es aussichtslos ist so etwas nachprogrammieren zu wollen, ausser vielleicht fuer Olli.

[divBy0]

Ich frage dann einfach mal so: Wo ist eigentlich das Problem, wenn z.B. eine BDE auf COM1 läuft und eine Messoftware auf COM2? Für mich klingt euer Problem so nach industriellem Einsatz.

Reicht doch wenn die Software sagt, Port belegt... dann hab ich halt Pech mit COM1 und muss COM2 nehmen, Industrie-PCs haben eh mehrere und eine Schnittstellenkarte kostet auch nicht die Welt.

Außerdem laufen dann die als Bsp. genannte BDE und die Messoftware parallel.

Korrigiert mich bitte, wenn ich was falsch verstanden hab'.


Gruß
Marc

[v2afrank]

Das Problem ist, dass Kunden oft nicht wissen welches Programm die Schnittstelle belegt. Bei sind oftmals Handyprogramme oder PDA-Programme die den Port belegen und sich ganz unscheinbar in die TNA legen (wo es dann von XP nach einiger Zeit auch ausgeblendet wird). Wenn dann die eigene Software sagen würde Com1 ist bereits von Software xy belegt, könnte ich mir manche Rückfragen ersparen.
Der Kunde käme dann selber auf die Idee das entsprechende Programm zu schliessen.

[divBy0]

Das wäre zwar ein tolles Feature, aber die wenigste Software zeigt an, welches Programm den Port belegt.

Ich bin leider noch nicht so fit, aber wäre es nicht möglich, das mit den entsprechenden Handles rauszufinden? Naja, ich muss mir für Handles und WindowsMessages erst mal ein gutes Tutorial oder Buch besorgen... :-D

[r_amse_s]

hallo nochmal,

also ich habe gar nicht vor malware oder so ein zeug zu coden.
hintergrund: neue laptops haben integrierte datenmodule mit dem man ins internet surfen kann und diese haben eine native software dabei. wenn man jetzt eine eigene (angenommen eine bessere :-) ) software dafür baut aber die native software im hintergrund läuft, dann ist halt das port besetzt...den rest kennt ihr