windows - Native x64 dll virker ikke

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har en ansøgning, som jeg kompilerer som x86-kode, men som en separat version, som x64-kode. Ansøgningen har i grunden to dele, en c # managed exe og en c ++ unmanaged dll. Jeg har problemer med sidstnævnte. På min udviklings-pc (Windows 7 64-bit, Visual Studio 2008) opretter jeg en opsætning med et implementeringsprojekt, og denne opsætning installerer programmet i Programfiler ... som det skal, og programmet kører. Jeg har også en test-pc (Windows 7 64-bit med næsten ingenting andet). Der installeres applikationen stadig i programfiler ... men den kører ikke, jeg får BadImageFormatException, når en funktion (enhver funktion) af den ustyrede dll kaldes. Problemet er, at mit eget projekt, der producerer dll'en også gør brug af ganske få frit tilgængelige biblioteker (f.eks. Glew32, openal, freeimage osv.) Jeg tog så meget omhu det er muligt at sikre, at jeg bruger x64-versionerne af disse biblioteker, men noget skal stadig være forkert. Af en eller anden grund er en af ​​de biblioteker, der bruges af min dll, ikke tilgængelig som x64-kode på test-pc'en, men den er på udviklings-pc'en. Det er i hvert fald den eneste forklaring, jeg har i øjeblikket, hvorfor mit opsætning virker på udviklings-pc'en, men ikke på test-pc'en.
Mit spørgsmål er: hvordan kan jeg finde ud af, hvor problemet er. Fejlmeddelelsen, jeg modtager, fortæller ikke nogen nyttige detaljer. Jeg forsøgte at analysere min dll med afhængighed, men det ser OK ud. Det lister mange afhængige biblioteker som X86 (disse er sandsynligvis systemfiler), men alle de, jeg bruger med vilje, er angivet som x64.
Er der nogen måde at teste, hvorfor Windows på min test-pc forsøger at køre DLL'en som x86-kode, selvom den skal være x64?
Tak.


Jeg har bemærket noget meget mærkeligt: ​​Min ansøgning bliver implementeret i mappen Programfiler, da den burde være for en x64-applikation, men den fejler ikke at køre. Men hvis jeg kopierer alle filerne i mappen, er den installeret til en anden mappe (inde i mappen Dokumenter), kører programmet perfekt.

Bedste reference


Kør Fusion Log Viewer i maskinen, hvor du vil diagnosticere problemet. Se omhyggeligt på logfilerne, og du vil se præcis hvilke dll'er der indlæses, og hvor fra. [2]

Andre referencer 1


Du har opbygget din .NET-eksekverbare (eller DLL) med Any CPU konfiguration, og du har givet x64/Win32 native DLL til Win32/x64 (dvs. forkert konfiguration).



  • På x64-systemer vil din .NET binære forsøge at indlæse den native DLL som om indfødt DLL er x64.

  • Og på 32-bit systemer vil det forsøge at indlæse 32-bit native DLL.


Andre referencer 2


Jeg fandt svaret. Problemet var slet ikke 64-bit dll. Et af de biblioteker, jeg ikke lavede, men jeg linker til (jeg ved ikke, hvilken som helst der) synes at forsøge at skrive en fil til applikationsmappen. Dette er selvfølgelig ikke tilladt inde i mappen Programfiler, medmindre du kører programmet som administrator. Undskyld for at stille hjælp til det forkerte spørgsmål.