Com (seriell) Schnittstelle belegt

[runger]

Hallo,

weiß irgendjemand wie man feststellt ob eine Com Schnittstelle (seriell) belegt ist oder nicht und wie man diese zwangsschliesst?
ich benutze Asych pro. Ich habe dort den Code durchgesteppt aber nur eine message gefunden (an das momentan laufende Programm) die zum schliessen auffordert.
Irgendwo in der registry (oder sonstwo) muss es doch einen Hinweis geben wer die Schnittstelle offen hat.

Wäre nett wenn mir jemand helfen könnte.
Rainer

[Muetze1]

Wer sie offen hat? Da müsstest du tief in die Trickkiste greifen - wird bestimmt nicht einfach.
Ob wer sie offen hat? Einfach versuchen zu öffnen, Windows verweigert dir dann den Zugriff gesetz den Fall, dass sie schon verwendet wird.
Zwangsschliessen? Bietet die WinAPI nicht an und mir ist soweit auch kein Weg bekannt dies zu realisieren. Einzige Möglichkeit die ich sehe, wäre den Prozess abzuschiessen, welcher die Schnittstelle offen hält, in der Hoffnung, dass diese mit geschlossen wird von Windows. Aber dazu müsstest du erstmal rausbekommen, welcher Prozess die Schnittstelle offen hält...

[runger]

Hm,

eine ganz harte Methode wäre den Treiber für die entsprechende Com zu deaktivieren und dann wieder zu aktivieren.

Rainer

[runger]

Hallo,

ich bin mit meinen Bemühungen etwas weiter. Mit WMI lässt sich über
win32_serialportconfiguration
und Isbusy ermitteln ob die Schnittstelle belegt ist oder nicht.
Es gibt auch einen Parameter der nach der ID des Prozesses riecht der die Schnittstelle
unter Kontrolle hat.
Wenn ich den jedoch auslese bleibt der resultierende String leer. (SettingsID)

Vielleicht hat jemand noch eine Idee dazu!
Rainer

[marabu]

Hallo Rainer,

SettingsID ist kein Handle zum owning process, sondern ein identifier für CIM-konformes Management der Schnittstelle. Da mehrere WMI Management Instanzen möglich sind, können die sich dort verewigen. Das ist meine Auffassung davon.

Was hast du vor? Willst du die Kontrolle über einen Port an dich reißen, auch wenn ein anderer Prozess diese Resource gerade im Zugriff hat?

Freundliche Grüße vom marabu

[runger]

Hallo marabu,

danke für deine Antwort, aber leider bekommt man über WMI fast nichts raus, sodass ich auf Vermutungen und rumstochern angewiesen bin.

Zu deiner Frage:
Eigentlich ist das Ziel rauszukriegen wer die Schnittstelle blockiert und dann den entsprechenden Prozess zu stoppen.
Leider tritt bei uns öfter der Fall auf, dass es völlig unklar ist wer die Schnittstelle blockiert.
Es ist weder im Taskmanager noch sonstwo irgendein Programm zu sehen das sie kontrolliert.
Abmelden nützt nichts, nur totaler shutdown und ausschalten, dann ist sie wieder frei.
Mir ist egal wie, aber ich bin mit allem zufrieden was diesen Zustand beendet eventuell auch mit einem Zwangsschliessen der Schnittstelle.

Rainer

[marabu]

Hallo Rainer,

ich vermute du wirst dich mit den undokumentierten Internas von Windows auseinandersetzen müssen um dein Ziel zu ereichen. Das Tool ProcessExplorer scheint in der Lage zu sein die Information zu beschaffen, die du brauchst.

marabu

[runger]

Hallo,

es hat sich herausgestellt, dass das Problem etwas mit dem 16 Bit Subsystem von WinXP zu tun hat. Nur alte DOS Programme die abgeschossen werden lassen die Schnittstelle offen.
Ohne totales Abschalten des PC's ist dann nichts mehr zu machen.

Rainer

[runger]

Hallo,

ich kann nicht glauben, dass, ausser mir, noch nie jemand dieses Problem gehabt hat. Gibt's denn hier niemanden der mir helfen kann?

Rainer

[marabu]

Hallo Rainer,

sieht so aus, als wärst du tatsächlich der erste, der ernsthaft nach einer Lösung sucht. Die Konstellation ist auch etwas verwegen, wenn auch durchaus realistisch - 16-bit Oldtimer als WOW subprocess laufen lassen und abschießen, wenn es Probleme gibt. Besser du schießt den WOW-Prozess gleich mit ab - oder hast du das gemacht und die Resourcen werden trotzdem nicht freigegeben?

Grüße vom marabu