Win 7 DllImport C# Нечетная ошибка, Неверный доступ к ячейке памяти?

Question

Я использую DllImport для доступа к некоторым функциям в C++ dll из моего приложения C#.

Этот код отлично работает на моем ноутбуке dev, который является Windows 7 64bit, сама dll 32-разрядная, поэтому я запускаю процесс размещения DLL на 32-битной основе и хорошо работает. Однако, когда я пытаюсь запустить тот же самый процесс на моей целевой машине, что опять же, Windows 7 64bit Ultimate, я получаю сообщение об ошибке «Недопустимый доступ к ячейке памяти». из процесса.

Я не уверен, в чем проблема, я просмотрел множество ресурсов в сети, и никто из них не решил это для меня. Я не понимаю, почему он отлично работает на моей dev-боксе, но не на цель?

Сама dll сама по себе, примеры, которые поставляются с dll, отлично работают на моем целевом поле (которые являются приложениями C#, выполняющими DllImport).

У кого-нибудь еще была эта проблема? Борьба с ним уже два дня!

Исключение: {"Unable to load DLL 'CLEyeMulticam.dll': Invalid access to memory location. (Exception from HRESULT: 0x800703E6)"}

Answer 1

Я имел эту проблему раньше. Я думаю, ваша проблема в том, что VS пытается открыть файл, но не имеет прав на его чтение. Вы должны убедиться, что учетная запись, которую вы используете, имеет доступ к DLL. Попробуйте отключить UAC, чтобы узнать, работает ли он, или используйте учетную запись администратора. Или попробуйте дать Full Control на DLL до Everyone.

EDIT: Вы можете запустить VS как администратор (щелкните правой кнопкой мыши -> Запуск от имени администратора)? Не могли бы вы поместить DLL на свой рабочий стол, чтобы попробовать? Существует ли разница в структуре папок между вашим рабочим компьютером и отсутствующим? Кроме того, может ли DLL работать нормально, если вы выполняете ее вне VS (попробуйте запустить ее также как администратор)?

НТН

Answer 2

DLL, загрузка может произойти сбой из-за неразрешенных зависимостей, поэтому открыть DLL на целевой машине с помощью Dependency Walker и посмотреть, есть ли какие-либо проблемы.

Answer 3

Я замечаю одно большое различие между вашей машиной dev и вашей целевой машиной, средой разработчиков. Убедитесь, что на целевом компьютере есть все необходимые перераспределители.

Редактировать: Я видел похожие проблемы, когда некоторые библиотеки dll были скомпилированы для разных версий .Net framework или если они были сделаны с различными версиями Visual Studio, так как распространяемые для каждой версии разные, а последние распространяемые точно обратная совместимость.

Answer 4

У меня были подобные проблемы раньше, попробуйте следующее.

• Проверьте версию .NET CLR. Существуют ли какие-либо SPs/KBs в вашей цели, которых нет в вашем dev?
• Попробуйте загрузить отладочную версию C++ DLL. Вы можете загрузить его? Если это не удастся, я предлагаю запустить ваше приложение под WinDBG в вашей цели. Как только исключение попадет, просто проанализировать -v даст вам много информации.
• В качестве следующего шага, Я попытался воспроизвести эту проблему в единичной тестовой среде. Образцы C#, которые вы упомянули, созданы для x64 VM? Если нет, попробуйте сделать это и попробуйте запустить результирующий образец двоичного кода в вашей целевой. Является ли проблема воспроизводимой?

Answer 5

У меня возникла проблема с 64-разрядной версией.NET («Любой процессор»), пытающийся загрузить 32-разрядную зависимую DLL-зависимость. У меня нет сообщения об ошибке передо мной, поэтому я не могу сказать, является ли это той же проблемой. Решение моей проблемы состояло в том, чтобы изменить мою сборку только на x86.

Если размер бит DLL меняется на каждом поле, возможно, существуют различия в размере структуры, поэтому ваша подпись PInvoke становится неправильной. Это может привести к переполнению буфера и вызвать повреждение стека в собственном коде.

Answer 6

Я столкнулся с подобной проблемой, когда перешел на win7. Возможно, вам понадобится установить ваш (64-разрядный) компьютер на 32-разрядный по умолчанию, используя следующую команду:

C: \ WINDOWS \ Microsoft.NET \ Framework64 \ v2.0.50727 \ Ldr64.exe setwow

Ref: http://social.msdn.microsoft.com/Forums/en/phoenix/thread/9a43e9a1-a744-4a1a-bb34-3604254c126b

Answer 7

Если вы получаете ошибку в вашем # приложение C, это сообщение часто указывает на то, нативный код сделал что-то противное в память о том, что ILM можно увидеть - проверить код в/называется ваш DllMain рутина - это называется до того, как ваш звонок действительно пройдет - если это неправильно, вы увидите этот результат

Answer 8

@Merlyn Morgan-Graham Мы столкнулись с аналогичной проблемой. Где мы построили приложение .Net с сборкой «Any CPU» и попытались использовать с 32-битной C++ Dll. Когда мы запускаем .Net-приложение в 64-битной ОС. Он работает как 64-битный исполняемый файл и, следовательно, имеет аналогичную проблему. После создания в X86 Loading, звонки в C++ Dlls работали абсолютно нормально. Еще одна важная вещь - если вы используете C++ DLL в своем .Net-коде. Было бы разумным количество маршаллинга, поэтому важно придерживаться типа сборки (т. Е. X86, любого процессора или X64).

Пожалуйста, проверьте ссылку также: Windows Vista: Unable to load DLL 'x.dll': Invalid access to memory location. (DllNotFoundException)

Answer 9

Очевидная, но, вероятно, хромой решением было бы построить C# сторону явно для 32-разрядных. Проверьте, как вы создаете из хоста proc - программно или путем заполнения ключей реестра или ... может быть, что в другом ящике он настроен на то, чтобы либо выполнить 64-битный хостинг, либо попытаться вызвать proc-proc, что означает загрузку. . Это параметр реестра, не забывайте, что для смешанных 23/64 бит случаев есть две ветви, которые нужно копать.

Answer 10

У меня была такая же проблема здесь Native loading works good. Loading from .net gives error Unable to load DLL 'my.dll': Invalid access to memory location

Проблема заключалась в DEP функции. Когда я включил DEP только для основных программ, это не дало эффекта. Но когда я полностью отключил DEP и перезагрузил свой сервер, ошибка исчезла. Еще одна вещь, которую я сделал - установил последние обновления для .net 4.0

Одна замечательная вещь - я не видел ошибок в DEP, просто закрываясь с ошибкой «память».