Serielle Schnittstelle wiederfreigeben
-
Hi,
Bei Windows 2000 oder XP kommt es manchmal vor, dass die VR Software DBView (wenn es mit offener serieller Schnittstelle abstuerzt) die serielle Schnittstelle nicht mehr freigibt. Die betreffende Schnittstelle bleibt dann bis zu einem Rechner-Reboot blockiert und kann von keinem anderen Programm mehr geöffnet werden. Gibt es eine Moeglichkeit, eine so blockierte Schnittstelle durch ein externes Programm wieder freizugeben? Kann das abstuerzende Programm vorher vielleicht noch selbst die Schnittstelle wieder schliessen?Gruss
eurer
dw-Inc
-
hm, interessante frage ... ist übrigens bei Win98 auch nicht anders und beschränkt sich nicht ausschliesslich auf den COM-Port sondern jegliche andere hardware wie modem, audio-karten usw.
wenn du ein eigenes programm schreibst kannst du es eventuell über exceptions versuchen und entsprechend in den CATCH-blöcken das device schliessen - daraus resultiert natürlich das du alle relevanten dinge in try/catch blöcke packen musst, was der performance nicht gerade zuträglich ist.
manchmal scheint es aber auch eine kettenreaktion zu sein. sprich programm macht mist und daraus resultierend schiesst sich der treiber ab - da helfen die exceptions auch nicht weiter. hatte sowas mal mit einem modem. immer nach dem 7. versuch - kein wählton - wurde der treiber nicht mehr geschlossen und ich musste die kiste neu booten.
-
Das darf aber eigentlich nicht sein (und bei mir ist das auch nicht). Schau Dir im Taskmanager an, ob der Process auch wirklich beendet ist. Wenn ja, dann wird ein anderer Process die Serielle geöffnet haben. Du kannst beispielweise mit dem Process Explorer herausfinden, um welchen Process es sich handelt. Wenn Du die Suche verwendest, mußt Du aber die richtigen Namen benutzen, also z.B. Serial0 für COM1. Aus dem Process Explorer heraus kann der Process dann wahlweise gekillt oder einfach nur das Handle geschlossen werden.
-
Das darf aber eigentlich nicht sein (und bei mir ist das auch nicht).
hmm, ist doch bei Win32 ein altbekanntes problem, das die hardware hängt, wenn ein entsprechendes programm abschwirrt. habe ich schon 1000x erlebt, auf verschiedenen versionen und auch rechnern. besonders beliebt sind da scheinbar AUDIO und SERIELLE hardware.
-
RockNix schrieb:
hmm, ist doch bei Win32 ein altbekanntes problem, das die hardware hängt, wenn ein entsprechendes programm abschwirrt.
Wie gesagt: Wenn es kein Programm gibt, das die Serielle offen hat, komme ich immer drauf. Dabei ist es egal, wie sich das zuvor belegende Programm beendet hat. Kann schon sein, daß Spielzeug-Windows da Probleme macht, die NTs funktionieren diesbezüglich sehr gut (bei mir). Allerdings kann ich nicht sagen, wie das bei AUDIO ist.
Gibt es denn Infos über diese Altbekannten, z.B. in Form von Einträgen in der KB?
[edit] Vielmehr interessiert mich das Ergbenis der Analyse mit dem Process Explorer. Ich bin ja mir fast sicher, daß da noch ein Process ist, der die Schnisstelle offenhält ... [/edit]
-
Kann schon sein, daß Spielzeug-Windows da Probleme macht, die NTs funktionieren diesbezüglich sehr gut (bei mir). Allerdings kann ich nicht sagen, wie das bei AUDIO ist.
also me/ entwickelt auf einer win2k maschine, meistens software, die auf hardware zugreift. gerade in der entwicklungsphase hat man ja des öfteren mal bugs wo das prog beim testen abschwirrt. ich habe da ständig stress mit blockierter hardware besonders audio, com und ab und an auch mal die netzwerkkarte - allerdings muss ich noch dazu sagen, dass es nicht immer an windows liegt, sondern auch an den treibern der kartenhersteller.
jedenfalls versuche ich schon seit langem eine lösung zu finden. so einer art sw, die belegte hardware anzeigen kann und bei bedarf die handles oder was auch immer da hängt, wieder freigibt - bisher leider erfolglos.
so far ...
-
RockNix schrieb:
jedenfalls versuche ich schon seit langem eine lösung zu finden. so einer art sw, die belegte hardware anzeigen kann und bei bedarf die handles oder was auch immer da hängt, wieder freigibt - bisher leider erfolglos.
Was ist denn mit dem Process Explorer? Der zeigt Dir alle Handles an (Strg+F und Du kannst sogar nach Deinem Device suchen) und kann sie notfalls auch wieder schliessen.
BTW: Ich arbeite auch auf W2K. Und gerade in der Entwicklungsphase geht auch mir mal was krachen. Aber eine serielle Schnittstelle ist dabei noch nie offen geblieben. Genau wie der USB-HID Treiber, der gibt nach Processs-Ende auch alles wieder frei. Und Dateien sind nach Process-Ende auch noch nicht geöffnet geblieben. Hab ich dann wohl immer Glück gehabt.
Eigentlich sollte Windows nach Process-Ende auch die Handle-Table abgrasen und alles wieder schöne schliessen. Das wäre eine Katastrophe, wenn dem nicht so wäre. Das sollte auch mit Deinen Audio-Devices funktionieren, so Du sie per CreateFile öffnest.
-
Was ist denn mit dem Process Explorer? Der zeigt Dir alle Handles an (Strg+F und Du kannst sogar nach Deinem Device suchen) und kann sie notfalls auch wieder schliessen.
muss ich mir bei gelegenheit mal genauer ansehen, habe das programm zwar, aber mich noch nicht so mit auseinander gesetzt.
Eigentlich sollte Windows nach Process-Ende auch die Handle-Table abgrasen und alles wieder schöne schliessen. Das wäre eine Katastrophe, wenn dem nicht so wäre
hmm, und das das clean-up von windows nicht so hundertprozentig hinhaut, ist auch nichts wirklich neues. nicht umsonst gibt es tools, die nichts anderes machen, als leaks aufzuspüren. wenn das bei windows alles so prima funktionierte, wären diese tools wohl überflüssig. naja, wenn ein process sauber beendet wird, denke ich funktioniert das im grossen und ganzen auch ordentlich. kritisch wirds bei den dingern denke ich, die es nicht mal mehr schaffen, dieses berühmte "ihre anwendung bla bla ...." auf den schirm zu bringen sondern sich gleich wortlos verabschieden, warum auch immer ...
-
RockNix schrieb:
hmm, und das das clean-up von windows nicht so hundertprozentig hinhaut, ist auch nichts wirklich neues.
Doch, das ist was neues. Du redest Dir da was ein.
RockNix schrieb:
nicht umsonst gibt es tools, die nichts anderes machen, als leaks aufzuspüren.
Was für Leaks?
RockNix schrieb:
wenn das bei windows alles so prima funktionierte, wären diese tools wohl überflüssig.
Was für Tools? Um irgendwelche Leaks aufzuspüren? Ich sprach bislang von der Freigabe der Kernel-Objecte. Und das funktionert. Terminiert ein Process, wie auch immer, wird der Referenzzähler des Objects entsprechend erniedrigt. Erreicht der Zähler 0, wird das Object freigegeben. Es kann durchaus sein, daß noch ein anderer Process auf Deine Hardware zugreift und noch ein Handle offenhält. Du mußt dann nur noch herausfinden, welcher Process das ist.
Unter Leaks verstehe ich irgendwie was anderes, etwa wie der mit dem SP4 frisch eingeführte CoCreateInstance()-Bug.
RockNix schrieb:
naja, wenn ein process sauber beendet wird, denke ich funktioniert das im grossen und ganzen auch ordentlich. kritisch wirds bei den dingern denke ich, die es nicht mal mehr schaffen, dieses berühmte "ihre anwendung bla bla ...." auf den schirm zu bringen sondern sich gleich wortlos verabschieden, warum auch immer ...
Siehe oben. Die Handle-Table wird abgeräumt. Wenn nicht, gibt es einen anderen Process, der das Object referenziert. Das kannst Du nun zukünftig schön mit dem Process Explorer verifizieren.