"xxx.exe ist keine gültige Win32-Anwendung", nachdem VS sie gerade erstellt hat
Ich habe erfolgreich eine WinAPI-Anwendung in Visual Studio 2015 (unter Verwendung der IDE) auf meinem Windows-7-64-PC entwickelt. Normalerweise teste ich das Programm im Release-Modus.
Ich habe dann einige Änderungen an meiner Quelle vorgenommen. Das Programm kompiliert und verlinkt ohne Fehler, aber das Programm hat sich nicht ganz so verhalten, wie ich es erwartet habe, also bin ich in den Debug-Modus gewechselt und habe versucht zu bauen und zu laufen. Erneut VS kompiliert und verlinkt ohne Fehler aber dann beschwert
"Programm kann nicht gestartet werden" f: \ dropbox \ blah \ x64 \ Debug \ xxx.exe ". 'f: \ dropbox \ blah \ x64 \ Debug \ xxx.exe' ist keine gültige Win32-Anwendung ".
Ich dachte, es wäre seltsam, also kehrte ich in den Freigabemodus zurück und versuchte es erneut - das Programm lief gut an. Ich habe einige Änderungen vorgenommen und einige Male neu erstellt, aber später erklärte VS
"Das Programm konnte nicht gestartet werden. f: \ dropbox \ blah \ x64 \ Release \ xxx.exe". 'f: \ dropbox \ blah \ x64 \ Release \ xxx.exe' ist keine gültige Win32-Anwendung ".
Ich habe versucht, alles zu reinigen, VS neu gestartet, sogar meinen PC neu gestartet .. aber alles ohne Erfolg, bekomme ich immer noch genau die gleichen Fehler.
BEARBEITEN: Nachdem ich ähnliche Berichte gelesen habe, habe ich versucht, die Dropbox-Synchronisierung zu unterbrechen. Es schien dann aber nur ein- oder zweimal zu funktionieren und dann kehrte das Problem zurück. Ich habe dann versucht, die Multiprozessor-Kompilierung abzuschalten, und das scheint die Freigabeversion meines Programms wieder laufen zu lassen. Ich habe seitdem bearbeitet-umgebaut-laufen viele (50+?) Mal ohne Problem - aber es weigert sich immer noch die Debug-Version zu laufen.
BEARBEITEN: FYI meine Antivirus-Software ist Microsoft Security Essentials
EDIT: Aufruf von dumpbin und Übergabe meiner (nicht laufenden Debug-Exe) erzeugt folgende Ausgabe:
%Vor%BEARBEITEN: Habe gerade versucht, compile-build-run auf einem anderen Rechner (windows-10-64) auszuführen, der per Dropbox verlinkt wurde und genau die gleichen Symptome hat, also im Release-Modus läuft, aber nicht im Debug-Modus.
BEARBEITEN: Auf Anraten von Michael Burr habe ich Dependance Walker auf meiner (nicht funktionierenden) Debug-Exe laufen lassen und diese Fehler gemeldet:
dann dachte ich, aus Neugierde würde ich mir ansehen, was Dep-Walker über meine (funktionierende) Release-Exe gesagt hat und festgestellt habe, dass ich genau die selbe Fehlerliste hatte! ... Nach mehr Suche fand ich diese SO-Frage , in der es abgeschlossen wurde: "Das Wesentliche davon: Wie jemand anders sagte, der Tool ist ein wenig veraltet und funktioniert nicht immer richtig mit einem neueren Betriebssystem. Behalten Sie also die Augen offen und lassen Sie sich nicht durch die fehlende API-MS-WIN-CORE-COM-L1-1-0.DLL irreführen. ... das Problem liegt wahrscheinlich ganz woanders. "
BEARBEITEN: Ich wechsle zwischen Debug- und Release-Modus aus dem Auswahlfeld links im Bild unten und ich starte das Programm, indem ich auf das grüne Dreieck klicke.
BEARBEITEN: Ich habe die Map-Datei für die Debug-Exe erstellt. Es ist zu groß, um es hier zu zeigen, aber es beginnt mit den folgenden Zeilen ...
%Vor%1 Antwort
Das ist fast sicher das Problem, Sie haben einen sehr großen Datenabschnitt. Seine Größe ist verdächtig ähnlich wie bei einem einzelnen ausführbaren Modul unter Windows. Sie können eine konsistentere Repro von diesem Beispiel C-Programm erhalten:
%Vor%Keine sehr gute Fehlermeldung btw, Microsoft hat für diesen Fall keinen Fehlercode reserviert. Und sicher, es wird nicht so gut, wenn Sie nahe an der Kante mit 0x77BB8000 sind. Das ausführbare Image muss zu einer einzelnen Ansicht der speicherzugeordneten Datei passen, die vom Loader erstellt wird, um den Code und die Daten im Speicher abzubilden. Die Ansicht hat eine harte Obergrenze von 2 Gigabyte, was für einen 32-Bit-Prozess und eine MMF-Größenbeschränkung auch für die 64-Bit-Version von Windows grundlegend ist.
Die Menge an Speicherplatz, die für diesen Datenabschnitt verfügbar ist, variiert von Lauf zu Lauf. Von der Ansichtsgröße werden die nicht abbildbaren Bereiche am Anfang und Ende des Adressraums und der für die Betriebssystem-DLLs (mindestens ntdll.dll und kernel32.dll) in einem 32-Bit-EXE-Prozess erforderliche Speicherplatz abgezogen. Und der Platz, den Sie aufgrund von ASLR verlieren (Address Space Layout Randomization), eine Zahl, die sich ändert. Und DLLs, die injiziert werden, wie die von Anti-Malware und Dropbox verwendeten.
Es kann nicht erraten werden, warum Ihr Datenabschnitt so groß sein muss. Bitten Sie den Linker, eine .map-Datei zu erstellen, damit Sie eine Aufteilung des Abschnitts erhalten, die große globale Variable sollte herausspringen. Stellen Sie sicher, dass Sie x64 anvisieren, damit Ihnen viel Adressraum zur Verfügung steht, und verwenden Sie den kostenlosen Speicher (malloc usw.), um große Arrays zuzuweisen.
Tags und Links c++ windows winapi visual-studio-2015