Frage

Ich habe einige C # Code geschrieben, der überprüft, ob ein Gerät auf jedem Serialport durch die Ausgabe eines Befehls auf den Hafen und das Hören auf eine Antwort vorliegt. Als ich festgelegt nur die Port-Geschwindigkeit, öffnen Sie den Port, den seriellen Strom erhalten und die Verarbeitung beginnen, es funktioniert 100% der Zeit. Allerdings arbeiten einige unsere Geräte mit unterschiedlichen Geschwindigkeiten und ich versuche, für ein Gerät mit verschiedenen Geschwindigkeiten zu sondieren, eine Verbindung sowie Gerät zur Erkennung Anwesenheit automatisch auszuhandeln.

Wenn ich in einem einzigen Thread all dies gibt es keine Probleme. Allerdings Timeout 3s bei zehn Geschwindigkeiten 30s pro serieller Schnittstelle ist, und es kann auch mehr sein. Daher der Wunsch, alle Ports gleichzeitig zu untersuchen.

Manchmal funktioniert dies. Manchmal Bluescreens Vista. Wenn ich Threads alle Ports sondieren es gleichzeitig fast immer Bluescreens. Wenn ich alles erzwingen in einem Thread ausführen es nie passiert.

Ein USB-Seriell-Prolific PL-2303-Adapter ist im Einsatz mit x64-Treiber.

@Vinko - danke für den Tipp auf das Lesen minidumps.

So nahe, wie ich sagen kann, ist der Kern des Problems, dass eine neue asynchronen I / O-Operation durch Starten von einem anderen Thread ist es möglich, eine ganz neue Bedeutung zu überlappen geben I / O, induziert im Inneren des Fahrers eine race-Bedingung. Da der Fahrer führt im Kernel-Modus, BLAM!

Epilog

Mit Ausnahme treten aus, nicht verwenden BeginXXX außerhalb des Handlers Rückruf und rufen Sie nicht BeginXXX bis EndXxx genannt haben, weil Sie eine Race-Bedingung in Treibercode veranlassen werden, die im Kernel-Modus ausgeführt wird.

Postscript

Ich habe festgestellt, dass dies auch Ströme an der Buchse gilt.

War es hilfreich?

Lösung

Windows-Treiber geschrieben Nachdem für eine dieser Art von Gerät einmal, mein Rat wäre nicht Ihre Zeit zu verschwenden mit WinDbg versuchen, zu beweisen, was Sie bereits wissen - d. H, dass der Fahrer Sie verwenden Buggy ist

Wenn Sie eine up-to-date-Treiber von der PL2302 finden können, versuchen Sie dann das, aber meine Empfehlung ist, dass, wenn Sie USB-> Serial-Adapter verwenden, die FTDI-basierte sind die besten. (Sie sind nicht die, die ich die Treiber schrieb, entweder ...)

Andere Tipps

Sie können auch "Automatischer Neustart" unter Systemeigenschaften \ Advanced \ Start-und Recovery \ Settings deaktivieren. Sobald Sie das deaktivieren, können Sie die BSOD sehen und für die Fehlermeldung suchen, zum Beispiel IRQL_LESS_OR_EQUAL, indem für diesen Fehler Namen suchen, können Sie in der Regel auf die Ursache des Problems verengen.

Btw, nicht viele Notebook kommt mit seriellen Schnittstellen heutzutage, so müssen Sie mit USB-Seriell-Konverter sein? Wenn das der Fall ist, könnte der Fahrer ein Problem gewesen, mit zu beginnen, da die meisten Hersteller den seriellen Port-Treiber als virtuelle Treiber geschrieben.

BSOD bedeutet in der Regel Buggy-Treiber.

Welche HW-Ports verwenden Sie? Ich habe BSODs mit SiLabs CP21xx USB-Seriell-Konverter Treiber hatte.

Es gibt FTDI-Treiber, die unter Vista x64 und win7 stabil sind. Ich schließe ich die Person, die sagte verwenden FTDI Chipsatz nur.

Die meisten der billigen Seriell-zu-USB-Dongles in den Geschäften in der Nähe von mir (Toronto, Kanada) scheinen FTDI Chips. Es ist nie auf dem Feld, so kaufe ich ein, und wenn es gut ist, gehe ich eine Kiste voll von ihnen kaufen.

W

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top