| |
| |
|
 | Hallo Profaner...
Hab mal wieder (seit längerem) was merkwürdiges:
Unter XP erhalte ich bei einer API zeitweise Zugriffsverletzungen, die ich mir nicht erklären kann (sind auch sehr selten und treten scheinbar nur in der compilierten EXE auf).
Bei einer anderen API verweigert diese mir zeitweise unter Windows95 grundlos den Dienst. Ich habe den Eindruck, daß dies vor allen Dingen bei APIs passiert, die auf die Registry zugreifen oder Systemeinstellungen ändern.
 Wer kennt außer mir noch dieses Problem? (Frank evtl.? Habe [...]  mit Interesse gelesen!)
Ich habe im Augenblick den unbegründeten Verdacht, daß das am Profan Messagehandling liegen könnte (Roland möge mir verzeihen) - habe der API ein DulcoIF verpasst, danach trat der Fehler nicht mehr auf. |
|
| |
| |
| |
|
|
Frank
Abbing | Hi,
um auf das von mir angesprochene Problem zu kommen: Es trat unter Assembler auf, allerdings innerhalb des Subclassings eines Profan-Hauptfensters.
Hab aber in einem anderen Forum gelesen, das jemand anderes genau das gleiche Problem hatte. Der hatte mit Profan aber sicher nichts zu tun... |
|
| |
| |
| |
|
|
| Hallo Frank...
Das scheint wirklich nicht zu meinem Problem zu passen.
Bei mir gibt es zum einen Probleme unter Windows95 mit der Funktion RegLoadKey, die zeitweise einfach keinen Hive laden will und zum anderen unter XP mit der Funktion LSAEnumerateAccountRights oder vielleicht der Funktion LSAFreeMemory, die zeiweise eine Zugriffsverletzung bringt.
Die Probleme treten, wie gesagt, nur unter den genannten Betriebssystemen und bei compiliertem Programm auf - äußerst merkwürdig... |
|
| |
| |
| |
|
|
 | |
| |
| |
| |
|
|
| Hallo IF...
Ich habe hier kein XP, auf dem ich programmieren kann - ich konnte deshalb bei den LSA-Funktionen noch nicht testen.
Bei RegLoadKey scheint das Problem u.a. vom Aussehen des gesamten Quelltextes abzuhängen. Fügt man irgendwo eine Zeile ein, tritt der Fehler unter Umständen fast gar nicht mehr auf.
Ich habe die Sache mit Fastmode noch nicht getestet - ich habe zuletzt direkt vor die besagte Funktion ein DulcoIF eingesetzt. Seitdem scheint es zu laufen. Merkwürdig... |
|
| |
| |
| |
|
|
| Hallo Profaner...
Nur ganz kurz - das Problem liegt doch nicht an Profan. Manche APIs scheinen extrem aggressiv auf einen GetLastError zu reagieren, der nicht 0 ist (evtl. durch das letzt FindNext$ hervorgerufen. Ich suche jetzt eher da den Fehler... |
|
| |
| |
| |
|
|
| Das Problem ist - glaube ich - gelöst. Der Fehler lag beim einem Quelltextschnipsel, den ich damals ohne selbst nachzudenken aus einer Hilfedatei von Uwe Passcal Niemeier übernommen habe:
KompilierenMarkierenSeparierendef @RegOpenKeyEx(5) !"ADVAPI32","RegOpenKeyExA"
def @RegQueryValueEx(6) !"ADVAPI32","RegQueryValueExA"
def @RegCloseKey(1) !"ADVAPI32","RegCloseKey"
declare Handle#
dim Handle#,4
declare Key#
dim Key#,100
string Key#,0="SoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer" Pfad des Schlüssels
declare Name#
dim Name#,100
string Name#,0="NoDrives" Name des Wertes
declare Size#
dim Size#,1
long Size#,0=4 Länge des Wertes: 4 Bytes bei DWord
declare Wert#
dim Wert#,4 Empfangsbereich für Wert: 4 Bytes bei DWord
print @RegOpenKeyEx($80000001,Key#,0,1,Handle#) 0 wenn ok
print @RegQueryValueEx(@Long(Handle#,0),Name#,0,0,Wert#,Size#) 0 wenn ok
print @RegCloseKey(@Long(Handle#,0)) 0 wenn ok
print hex$(long(Wert#,0)) Wert als Hex$ ausgeben
dispose Handle#
dispose Key#
dispose Wert#
dispose Name#
dispose Size#
waitkey
Dabei wird die Variable für die Größe des dimensionierten Bereichs (size#) mit 1 dimensioniert. Sowohl Long als auch Windows selbst setzen aber einen 4 Byte Wert. Dabei werden evtl. Bereiche überschrieben, in denen Variablen stehen, die ich danach noch für andere APIs nutze RegQueryValueEx arbeitet aber korrekt!.
Ob und was da überschrieben wird, hängt von der Speicherorganisation, d.h. vom Aufbau des Programmes und vom OS (bzw. den noch laufenden Programmen) ab => es kommt zu Fehlfunktionen im Programm oder auch zu Zugriffsverletzungen, deren Ursprung nicht logisch zu lokalisieren ist .
Ahnliche Sachen können auch Auftreten, wenn man einer API einer Größeren Bereich für eine Variable übergibt als man vorher dimensioniert hat. Auch hier meckert Windows zumindestens nicht immer und bringt - je nach Größe des eigenen Programmes, im Hintergrund laufender Programme, OS, Programmstarts etc. - unterschiedliche Fehlermeldunge, deren Ursache nicht zu lokalisieren ist!
Wer also mit unerklärlichen Programmfehler, Systemabstürzen, Zugriffsverletzungen... kämpft, sollte unbedingt die APIs kontrollieren, bei denen in einem Parameter die Größe eines dimensionierten Bereichs übergeben wird.
Ich hoffe, ich kann anderen mit diesem Beitrag heftige Kopfschmerzen ersparen...
Gruß
AH |
|
| |
| |
| |
|
|
| | Nochmals: Wie gesagt, nicht die API die den Fehler enthält macht Probleme, sondern irgendwelche darauf folgende Programmteile (nach oben schieb)! |
|
| |
| |
| |
|
(911)
Deutsch
English
Français
Español
Italia