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

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

4 голосов
/ 29 декабря 2008

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

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

Теперь у меня есть Windows Vista Home 64-bit, которая заставляет меня крутиться. Примеры 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 или что-то в этом роде)?

Ответы [ 3 ]

2 голосов
/ 29 декабря 2008

Есть несколько вещей, которые вы должны помнить на 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-битное приложение и посмотреть, что произойдет.

1 голос
/ 20 августа 2010

Возможно, проблема в DEP.

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

bcdedit.exe /set {current} nx AlwaysOff

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

bcdedit.exe /set {current} nx AlwaysOn

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

wmic OS Get DataExecutionPrevention_SupportPolicy

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

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

0 голосов
/ 29 декабря 2008

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

  1. Запустите монитор процесса с выходным фильтром для процесса сбоя. Посмотрите, есть ли какие-то странные ошибки.

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

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

...