Hallo,
heute kam die neue Bestellung der IO Warriors an. 3 IOW 40 mit Application board. Hab alles aufgelötet und dann gings auch schon los mit dem Programmieren.
Ich hatte bereits ein Board mit dem ich auch schon mein Programm geschrieben habe. Nur leider ist das nun schon verbaut und ich komm da zum testen derzeit nicht dran.
Jedenfalls schießt sich mein Visual Studio 6.0 immer ab wenn ich das SimpleIO Beispiel gestartet habe und dann beende bzw auch wenn ich das Programm über den Debugger stoppe.
Woran kann das liegen, dass sich das Programm dermaßen abschießt? Liegt das an der neuen API Version?
Gruß
Holger
Visual Basic steigt aus
Moderator: Guido Körber
Gleiches Problem
Hallo Holger,
hast Du das Problem mit Visual Studio lösen können?
Bei mir treten die gleichen Schwierigkeiten auf. Programm schreiben, Proramm testen und VB6 Absturz.
Gruß Peter
hast Du das Problem mit Visual Studio lösen können?
Bei mir treten die gleichen Schwierigkeiten auf. Programm schreiben, Proramm testen und VB6 Absturz.
Gruß Peter
-
MrReaction
- Posts: 2
- Joined: Thu Apr 22, 2004 11:10 am
- Location: Ulm
-
Robert Marquardt
- Posts: 543
- Joined: Mon Dec 01, 2003 6:09 pm
-
MrReaction
- Posts: 2
- Joined: Thu Apr 22, 2004 11:10 am
- Location: Ulm
Hallo,
nach dem Erscheinen der API 1.5 wollte ich auch mal wieder etwas mit dem IO-W 40 experimentieren und die neuen Funktionen mal testen. Leider habe jetzt mit der neuen DLL auch das Problem, dass sich VB 6 verabschiedet sobald ich das Programm (Simple_IO) beende.
Mit der alten DLL gab es ein ähnliches Problem, wenn man im Debug Modus das Programm mitten drin bendet (betätigen des kleinen Rechtecks unter der Menüleiste) hat, ohne die IowKitCloseDevice Funktion vorher aufzurufen. Daher liegt es nahe, zu vermuten, das die neue Funktion möglicherweise den Iow nicht richtig abmeldet und dann ähnliches passiert.
Ich habe auch noch mal einen Auszug (den ich für Relevant halte) aus dem Eventlog vom Dr.Watson:
Anwendungsausnahme aufgetreten:
Anwendung: VB6.exe (pid=1504)
Wann: 27.12.2006 @ 14:35:56.007
Ausnahmenummer: c0000005 (Zugriffsverletzung)
*----> Systeminformationen <----*
Computername: ********
Benutzername: ******
Prozessoranzahl: 1
Prozessortyp: x86 Family 15 Model 2 Stepping 9
Windows 2000-Version: 5.0
Aktuelles Build: 2195
Service Pack: 4
Aktueller Typ: Uniprocessor Free
Firma: ******
Besitzer: ********
:
:
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
02E4FF40 77E9A150 02E4FF18 00000001 00000000 00000000 ntdll!NtWaitForMultipleObjects
78008500 74C08578 56D0FF02 00010BE8 85F08B00 6A0875F6 kernel32!WaitForMultipleObjects
03F11CA1 00000000 00000000 00000000 00000000 00000000 <nosymbols>
Statusabbild für Threadkennung 0x6f0
eax=00000102 ebx=031e0014 ecx=00000101 edx=ffffffff esi=77e9a001 edi=000000fa
eip=031b3613 esp=033aff4c ebp=033affb4 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
Funktion: <nosymbols>
031b3609 ???
031b360a ???
031b360b ???
031b360c ???
031b360d ???
031b360e ???
031b360f ???
031b3610 ???
031b3611 ???
031b3612 ???
FEHLER ->031b3613 ???
031b3614 ???
031b3615 ???
031b3616 ???
031b3617 ???
031b3618 ???
031b3619 ???
031b361a ???
031b361b ???
031b361c ???
031b361d ???
031b361e ???
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
033AFF48 031E0014 00000000 031E0014 00000000 00000000 <nosymbols>
033AFFB4 77E7B396 031E0014 031E0014 00000000 031E0014 <nosymbols>
033AFFEC 00000000 00000000 00000000 00000000 00000000 kernel32!lstrcmpiW
Falls das nicht reicht, kann ich auch mal den kompletten Log rein stellen oder schicken.
IOW 40 V1.0.2.1
VB6 Professional SP6
Gruß Mike
nach dem Erscheinen der API 1.5 wollte ich auch mal wieder etwas mit dem IO-W 40 experimentieren und die neuen Funktionen mal testen. Leider habe jetzt mit der neuen DLL auch das Problem, dass sich VB 6 verabschiedet sobald ich das Programm (Simple_IO) beende.
Mit der alten DLL gab es ein ähnliches Problem, wenn man im Debug Modus das Programm mitten drin bendet (betätigen des kleinen Rechtecks unter der Menüleiste) hat, ohne die IowKitCloseDevice Funktion vorher aufzurufen. Daher liegt es nahe, zu vermuten, das die neue Funktion möglicherweise den Iow nicht richtig abmeldet und dann ähnliches passiert.
Ich habe auch noch mal einen Auszug (den ich für Relevant halte) aus dem Eventlog vom Dr.Watson:
Anwendungsausnahme aufgetreten:
Anwendung: VB6.exe (pid=1504)
Wann: 27.12.2006 @ 14:35:56.007
Ausnahmenummer: c0000005 (Zugriffsverletzung)
*----> Systeminformationen <----*
Computername: ********
Benutzername: ******
Prozessoranzahl: 1
Prozessortyp: x86 Family 15 Model 2 Stepping 9
Windows 2000-Version: 5.0
Aktuelles Build: 2195
Service Pack: 4
Aktueller Typ: Uniprocessor Free
Firma: ******
Besitzer: ********
:
:
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
02E4FF40 77E9A150 02E4FF18 00000001 00000000 00000000 ntdll!NtWaitForMultipleObjects
78008500 74C08578 56D0FF02 00010BE8 85F08B00 6A0875F6 kernel32!WaitForMultipleObjects
03F11CA1 00000000 00000000 00000000 00000000 00000000 <nosymbols>
Statusabbild für Threadkennung 0x6f0
eax=00000102 ebx=031e0014 ecx=00000101 edx=ffffffff esi=77e9a001 edi=000000fa
eip=031b3613 esp=033aff4c ebp=033affb4 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
Funktion: <nosymbols>
031b3609 ???
031b360a ???
031b360b ???
031b360c ???
031b360d ???
031b360e ???
031b360f ???
031b3610 ???
031b3611 ???
031b3612 ???
FEHLER ->031b3613 ???
031b3614 ???
031b3615 ???
031b3616 ???
031b3617 ???
031b3618 ???
031b3619 ???
031b361a ???
031b361b ???
031b361c ???
031b361d ???
031b361e ???
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
033AFF48 031E0014 00000000 031E0014 00000000 00000000 <nosymbols>
033AFFB4 77E7B396 031E0014 031E0014 00000000 031E0014 <nosymbols>
033AFFEC 00000000 00000000 00000000 00000000 00000000 kernel32!lstrcmpiW
Falls das nicht reicht, kann ich auch mal den kompletten Log rein stellen oder schicken.
IOW 40 V1.0.2.1
VB6 Professional SP6
Gruß Mike
Hallo,
habe beim Testen mit ein paar weiteren "alten" Programmen noch ein Problem mit der API 1.5 festgestellt. Fast keines meiner Programme läuft mehr. Sie hängen sich nach wenigen Sekunden (ms) auf. Ohne Fehlermeldung oder exakte Reproduzierbarkeit. Sowohl im Debug Modus als auch Kompiliert. Vermutlich liegt es an der IowKitReadImmediate() Funktion. Es ist zumindest die einzige Funktion die ich in den nicht mehr funktionierenden Programmen zusätzlich verwende. Hauptsächlich um mit einem Timer zwischen 20 - 500 ms Ports abzufragen.
Ich habe auch mal einen Zähler rein gehängt und nur zwischen 4 und max. 130 Abfragen geschafft. Dann war es vorbei. Übrigens unabhängig von der Abfragegeschwindigkeit.
Habe auch noch mal den Schritt zurück gemacht zur alten DLL.. da gehts wieder. Und ich habe es auch auf mehreren Rechnern getestet, mit dem gleichen Ergebnis.
Gruß Mike
habe beim Testen mit ein paar weiteren "alten" Programmen noch ein Problem mit der API 1.5 festgestellt. Fast keines meiner Programme läuft mehr. Sie hängen sich nach wenigen Sekunden (ms) auf. Ohne Fehlermeldung oder exakte Reproduzierbarkeit. Sowohl im Debug Modus als auch Kompiliert. Vermutlich liegt es an der IowKitReadImmediate() Funktion. Es ist zumindest die einzige Funktion die ich in den nicht mehr funktionierenden Programmen zusätzlich verwende. Hauptsächlich um mit einem Timer zwischen 20 - 500 ms Ports abzufragen.
Ich habe auch mal einen Zähler rein gehängt und nur zwischen 4 und max. 130 Abfragen geschafft. Dann war es vorbei. Übrigens unabhängig von der Abfragegeschwindigkeit.
Habe auch noch mal den Schritt zurück gemacht zur alten DLL.. da gehts wieder. Und ich habe es auch auf mehreren Rechnern getestet, mit dem gleichen Ergebnis.
Gruß Mike