Programm mit Windows2000 compiliert, läuft nicht unter WinXP



  • Hallo,

    ich habe ein Programm zur Abfrage von Daten aus einer Datenbank auf einem Win2000-Rechner geschrieben.
    Das compilierte exe-file funktioniert auf einem Win2000-Rechner oder auf einem WinNT-Rechner hervorragend.
    Spiele ich das exe-file auf einen WinXP-Rechner, erhalte ich nach Ausführung die Fehlermeldung:
    "An unsupported operation was attempted"

    Das Programm müßte doch eigentlich auf einem XP-Rechner genauso laufen, oder ?

    Kann mir jemand weiterhelfen ?



  • Ich bermute mal, dass Du ums debuggen nicht drum rum kommen wirst...
    Normalerweise sollte es ohne Probleme laufen, aber es scheint so, als ob Dein Programm was macht was nicht zulässig ist (z.B. Code-Injection/Modification, was ab XP-SP2 per default nicht mehr erlaubt ist)



  • Hallo Jochen,

    ich habe das Programm wie gesagt auf einem Win2000-Rechner erstellt. Wenn ich es kompiliere, werden mir keine Fehlermeldungen angezeigt.
    Oder warte mal, um genau zu sein meldet mir das Ausgabefenster viele Warnungen:

    hier nur ein paar Beispiele:
    'DBX.exe': 'C:\WINNT\system32\MFC71.dll' geladen, Symbole geladen.
    'DBX.exe': 'C:\WINNT\system32\msvcr71.dll' geladen, Symbole geladen.
    'DBX.exe': 'C:\WINNT\system32\KERNEL32.DLL' geladen, Erforderliche DBG-Datei wurde nicht gefunden oder konnte nicht geladen werden.
    'DBX.exe': 'C:\WINNT\system32\GDI32.DLL' geladen, Erforderliche DBG-Datei wurde nicht gefunden oder konnte nicht geladen werden.

    Die Ausführung funktioniert aber dann trotzdem einwandfrei. Hängt mein oben beschriebenes Problem vielleicht mit den Warnungen zusammen. Wenn ja, wo bekomme ich die fehlenden DLLs her, oder was könnte ich sonst noch falsch machen ?
    Danke für jeden Hinweis.



  • In den FAQs habe ich gerade gelesen dass das ASSERT()_Makro manchmal die Ursache sein kann. Dieses habe ich in meiner Anwendung jetzt wie empfohlen gegen VERIFY() ausgewechselt. War aber leider nicht die Ursache.

    Manchmal liegt die Ursache dafür, dass das Debug.exe im Gegensatz zum Release.exe problemlos läuft, daran, dass zufällig irgendwelcher Speicher überschrieben wird. Das könnte bei mir durchaus die Ursache sein. Mein Ausgabe-Fenster meldet nämlich:

    Eine Ausnahme (erste Chance) bei 0x77e97e54 in DBX.exe: 0xC0000005: Zugriffsverletzung-Leseposition 0x00000002.
    Eine Ausnahme (erste Chance) bei 0x77e97e54 in DBX.exe: 0xC0000005: Zugriffsverletzung-Leseposition 0x00000002.
    Eine Ausnahme (erste Chance) bei 0x77e97e54 in DBX.exe: 0xC0000005: Zugriffsverletzung-Leseposition 0x00000178.
    Eine Ausnahme (erste Chance) bei 0x77e97e54 in DBX.exe: 0xC0000005: Zugriffsverletzung-Leseposition 0x00000001.
    Eine Ausnahme (erste Chance) bei 0x77e97e54 in DBX.exe: 0xC0000005: Zugriffsverletzung-Leseposition 0x0000004c.
    Eine Ausnahme (erste Chance) bei 0x77e97e54 in DBX.exe: 0xC0000005: Zugriffsverletzung-Leseposition 0x00000064.

    Wie kann ich solche Zugriffsverletzungen vermeiden. Diese Meldungen habe ich in meinem Projekt schon von Anfang an gehabt, als ich noch im Hello-World-Stadium war.
    Bin ziemlich ratlos.
    Unter Windows2000 läuft das Programm einwandfrei, trotz Zugriffsverletzungs-Warnungen.



  • hmm, WANN genau passiert es? direkt beim Ausführen der Applikation? Evt. eine abgespeckte Version erstellen und diese testen...



  • Danke sky21

    ich werde jetzt die Entwicklungsumgebung auf einem WinXP-Rechner installieren. Dann hoffe ich, mit dem Debugger die Stelle zu finden, an der das Programm aussteigt.



  • Hallo Jochen,

    ich habe auf meinem XP-Rechner SP1. Trotzdem habe ich das beschriebene Problem.



  • bei mir ist´s genau anders herrum, ich schreibe mein programm auf xp und es läuft nicht unter NT 👎



  • Wer fängt denn diese Zugrifssverletzungen ab!?
    ALso mich wundert es nicht, dass es nur Zufall ist dass es läuft...



  • Sollche Meldungen habe ich oft wenn ich unter XP Funktionen verwende die es so unter <= 2000 nicht gibt, sich geändert haben oder die DLL-Hölle unter Windows zuschlägt.



  • Unix-Tom schrieb:

    Sollche Meldungen habe ich oft wenn ich unter XP Funktionen verwende die es so unter <= 2000 nicht gibt, sich geändert haben oder die DLL-Hölle unter Windows zuschlägt.

    Kannst Du mir mal ein Beispiel nennen????

    Der OP hat aber genau der gegenteilige Problem 😉



  • als Beispiel MDAC
    Es gibt aber genug Funktionen die es nur in höheren BS gibt. So aus dem Stand kann ich Dir nun keine nennen weil ich in letzter Zeit viel NET gemacht habe.
    Achja z.B. gab es die Funktion zum Duchsichtigmachen der Fenster erst ab XP bzw. war im SDK drin das man erst auf einem anderen BS installieren musste. Ich weiß blödes Bsp. aber es ist mir als erstes eingefallen.
    Das er genau das er Probleme mit XP hat weiß ich aber es wäre auch mal ein Ansatz das zu überprüfen.
    Vielleicht haben sich die Parameter einer Funktion geändert.
    Dann wird die Operation auch nicht supportet.



  • Du kannst mir gerne das Programm mal zum Download wo anbieten und ich sehe nach.
    Dann braucht nicht auf einem XP VS installieren.



  • Ich kann aber nach Deinen Aussagen nicht verstehen, warum hier irgendwas eine Exception werfen sollte!?
    Exceptions werden nur geworfen wenn Du was falsch gemacht hast...



  • Im ersten Post ist nicht von einer Zugriffsverletzung die Rede.
    Die Exception erwähnt er erst selbst.
    Das mit der "An unsupported operation was attempted" war bei mir damals eine Dialogbox. Wenn aber eine Funktion aufgerufen wird die nicht supportet wird dann fliegt auch eine Exception.

    Übrigens findet Google zu "An unsupported operation was attempted" sehr viel eEinträge welche immer von einer falschen DLL sprechen.



  • Das Programm ist immer dann ausgestiegen wenn ein Flex-Grid angezeigt werden sollte.
    Da ich das anzuzeigende Flex-Grid bei WinXP vorher nicht registriert habe.

    Wird dieses mit folgenden Schritten dem Betriebssystem bekannt gemacht funktioniert alles:

    Dies geschieht durch folgende Schritte:

    - MS-DOS-Eingabeaufforderung öffnen
    - in das Verzeichnis wechseln, wo sich das ActiveX-Steuerelement auf dem eigenen Rechner befindet
    - den Befehl regsvr32 ausführen. Als Argument der Befehlszeile den Namen des ActiveX-Steuerelements angeben. Soll z.B. das o.a. Steuerelement Msflxgrd.ocx registriert werden, das sich im Verzeichnis C:\Windows\System befindet, folgenden Befehl an der MS-DOS-Eingabeaufforderung eingeben:
    C:\WINDOWS>CD system
    C:\WINDOWS\SYSTEM>regsvr32 MSFLXGRD.OCX

    WinXP weiß jetzt, wo das ActiveX-Steuerelement steht und wie es heißt.



  • Ist eine Dialogbox und keine Exception.


Log in to reply