Использование 32-битного COM-объекта с C# или VBS на Vista 64-бит и получение ошибки 80004005

Question

Мне нужно немного читать мысли, так как я стараюсь делать то, что я не совсем понимаю.

Существует 32-разрядное приложение (электронное торговое приложение CQG), которое предоставляет COM API для внешнего доступа. У меня есть примеры программ и скриптов, которые получают доступ к этому API из Excel, .NET (C++, VB и C#) и оболочки VBScript. У меня эти .NET-приложения как исходный код и как скомпилированные исполняемые файлы (32-разрядные, скомпилированные в Windows XP).

Теперь у меня Windows Vista Home 64-бит, который заставляет мою голову вращаться. Примеры Excel работают очень хорошо (в Excel 2003). Скомпилированные исполняемые файлы .NET также работают.

Но когда я пытаюсь запустить образец .NET C#, преобразованный и скомпилированный Visual Studio C# Expression, или запускает скрипт VBScript, я получаю ошибку 80004005 при попытке создать объект. Первоначально приложение .NET также дало мне 80040154, но потом я понял, как заставить его производить 32-битный код, а не 64-битный, поэтому теперь ошибки в C# и VBScript-приложениях одинаковы. Это все, что я получил сейчас.

И да, я попытался запустить 32-разрядные версии cscript.exe/WScript из папки SysWOW64 на моем VBS, но результат все тот же (80004005).

Как решить эту проблему? Я почти готов поверить, что это практически невозможно, но тот факт, что Excel VBA работает, и исполняемые файлы .NET, скомпилированные в Windows XP, просто прекрасны, просто меня злит. Должен быть способ победить это (какой-то секрет, который, вероятно, знают только разработчики Windows Vista)! Буду признателен за любую помощь!

PS: Я считаю, что образцы кода не имеет смысла здесь, но это линия VBScript, которая терпит неудачу:

Set CEL = WScript.CreateObject("CQG.CQGCEL.4.0", "CEL_") 

И это C#:

CQGCEL CEL = new CQGCEL(); 

Обновление: Забыла скажем, UAC выключен, конечно. И я работаю со счета с правами администратора.

Я также пробовал смотреть, какие ключи реестра читаются с помощью Process Monitor, но все выглядит нормально для GUID этого объекта. Я не мог распознать некоторые другие GUID, поэтому я не уверен, были ли они критическими или нет.

Есть ли вероятность, что этот объект COM использует Internet Explorer и получает неправильный (например, Internet Explorer 7 вместо движка Internet Explorer 6 или что-то в этом роде)?

Answer 1

Есть много вещей, которые вы должны помнить с помощью 64-битной машины.Это некоторые вещи, которые застали меня в прошлом.

1. здание для любого процессора в .NET означает он будет работать, как 64 бит на 64 битной машине.
2. Множество компонентов COM похоже только на 32 бит (я знаю, это является обобщением, но часто это ). Чтобы использовать их, вам необходимо создать приложение как 32 бит (x86).
3. 64-разрядная версия Windows имеет различные 32 и 64-битные реестры узлов. Например, если вы запустили regedit как 64 бит, вы увидите HKLM \ Software \ Wow6432Node и HKCU \ Software \ Wow6432Node. В этом содержится вся информация для 32 бит приложений.

Мое предложение было бы построить как 32-битное приложение и посмотреть, что произойдет.

Answer 2

Несколько полезных вещей, которые вы можете попробовать:

1. Run process monitor с выходом фильтрованного в процессе неисправного. Проверьте, не сообщаются ли какие-либо нечетные ошибки.

2. Аналогичным образом, попробуйте запустить под неуправляемым отладчиком и посмотреть, не выбрасываются ли какие-либо другие исключения первого шанса. Это также позволит вам подтвердить, загружается ли COM-библиотека inproc COM в этот процесс.

3. Попробуйте выключить UAC и посмотреть, что произойдет.

Answer 3

Проблема, вероятно, в DEP.

У меня была такая же проблема, как и у вас, и получил некоторую помощь от технической поддержки в CQG. Предотвращение выполнения данных включается Windows Vista & Windows 7 по умолчанию. Вы можете выключить его в командной строке с правами администратора с помощью

bcdedit.exe /set {current} nx AlwaysOff 

Позже, если вам нужно, вы можете включить его обратно с

bcdedit.exe /set {current} nx AlwaysOn 

Reboot не предлагается, но необходимо. Вы можете проверить свою политику DEP с помощью

wmic OS Get DataExecutionPrevention_SupportPolicy 

где 0 является Always off, 1 является Always On, 2 является Opt in (значение по умолчанию), и 3 является Opt Out.

После смены шахты на Always Off и перезагрузки я смог скомпилировать, не выбрасывая ошибку 80004005.