trace:reg:NtOpenKey (0x20c,L"WbemScripting.SWbemLocator\\CLSID",f003f,0x32e6c0) trace:reg:NtOpenKey <- (nil) ... trace:reg:NtOpenKey (0x20c,L"winmgmts\\CLSID",f003f,0x32d9f4) trace:reg:NtOpenKey <- (nil) Поведение поменялось, когда, пробуя подставить виндовые библиотеки, зарегистрировал wbemdisp.dll - необходимый ключ хранится в ней. Теперь - ошибка: err:ole:apartment_getclassobject DllGetClassObject returned error 0x80004002 err:ole:create_server class {172bddf8-ceea-11d1-8b05-00600806d9b6} not registered fixme:ole:CoGetClassObject CLSCTX_REMOTE_SERVER not supported err:ole:CoGetClassObject no class object {172bddf8-ceea-11d1-8b05-00600806d9b6} could be created for context 0x15 Оболочка 1С сообщает о возникшей ошибке и предлагает закрыть программу.
[перенесено из #3066] Добавили в wine библиотеку wbemdisp. Пользы это никакой не принесло. В библеотеке сделаны ISWbemLocator и ISWbemServices. Ещё запрашивается IConnectionPointContainer и несколько других интерфейсов. На данный момент падает в модуле 1С после обращения к IClassFactory_QueryInterface с riid, равным NULL (!) Так не бывает, на этом идеи пока закончились...
В wbemprox_IClassFactory_QueryInterface передаются riid и ppvObj, равные null. Если выделять память под ppvObj и записывать туда значение (например, какой-нибудь интерфейс), то падает при попытке обратиться к нему. Если сделать *ppvObj = NULL; то падает при чтении нулевого адреса.
Скорее, проблему нужно искать в том, что при выполнении программы библиотеке вообще приходит подобная задача (тем более, с такими странными указателями). А падение дальше - лишь следствие того, что почему-то этот QueryInterface вызван в этот момент.
Нужен тест, воспроизводящий проблему. В существующем тесте (в отличие от 1С) не вызывается ConnectServer и не получается интерфейс ISWbemServices.
Воспроизведение - в бутылке rt/9051-2 wbemdisp является ссылкой на библиотеку в моём проекте: /srv/kondratyuk/Projects/wine/dlls/wbemdisp/wbemdisp.tlb
(In reply to comment #4) > Нужен тест, воспроизводящий проблему. > В существующем тесте (в отличие от 1С) не > вызывается ConnectServer и не получается > интерфейс ISWbemServices. > Тест на vbs правельный, но для того чтобы получить services надо знать строку подключения....те самые строки с мусором что мы получали из 1С. как только выясним строку подключения, необходимо просто добавить параметры подключения со строкой вот в эту строку и должно заработать Set wbemServices = wbemlocator.ConnectServer <Сюда добавить параметры через запятую>
Глупая ошибка. Унаследовали SWbemLocator от IUnknown вместо IDispatch. Поэтому функция, к которой обращается программа стала вместо GetTypeInfoCount - ConnectServer. Переделал на IDispatch, попутно дополнив интерфейс пропущенным в конце методом...
QueryInterface возвращал SWbemLocator при запросе IConnectionPointContainer. Далее предполагался метод Enum..., который у нас заменялся на GetTypeInfoCount. Возвращаемая единица представлялась адресом интерфейса, после чего программа просто падала. Исключил все левые IID из SWbemLocator_QueryInterface. Падать перестало, смотрим дальше...
Запрашиваются (в порядке появления в логах): 00000126-0000-0000-c000-000000000046 (IRunnableObject) e7210190-61f4-11d4-941d-008048da11f9 fd7b6cc3-dc8e-11d2-b8d0-008048da0335 b196b283-bab4-101a-b69c-00aa00341d07 (IProvideClassInfo) a6ef9860-c720-11d0-9337-00a0c90dcaa9 (IDispatchEx)
Попробуем добавить IProvideClassInfo для начала. Программа пытается получить ITypeInfo через IProvideClassInfo::GetClassInfo
Добавил IProvideClassInfo 1С падает при обращении по нулевому указателю после вызова IProvideClassInfo:GetClassInfo. Вроде мы не возвращаем нигде нулей...
Не вижу ничего (кроме wbemprox_ISWbemLocator_QueryInterface), откуда мог бы возвращаться левый указатель... При возврате ненулевого значения в *ppvObj падает именно при переходе к этому значению-адресу, игнорируя возвращаемые E_NOINTERFACE. С нулём, похоже, то же самое.
IRunnableObject добавлен В нём вызывается метод Run, имеющий только входные параметры. Что бы мы ни возвращали - программе всё равно. Падает по-прежнему...
Остались только эти два (неизвестных) интерфейса: {e7210190-61f4-11d4-941d-008048da11f9} {fd7b6cc3-dc8e-11d2-b8d0-008048da0335} Падения носят случайный характер, то read, то write, то unhandled exception... Есть вариант - создать левый интерфейс с множеством методов (func1, func2, func3) и посмотреть, что же хочет программа от них. Или хотя бы - в каком интерфейсе будет падать.
В виндовом WbemScripting не существует (не поддерживается через SWbemLocator): IDispatchEx IRunnableObject ISWbemServices e7210190-61f4-11d4-941d-008048da11f9 fd7b6cc3-dc8e-11d2-b8d0-008048da0335 Убрал лишнее, оставив только ISWbemLocator и IProvideClassInfo
Скорее всего, проблема в IProvideClassInfo_GetClassInfo. Нынешний хак на его реализацию приводит к падениям. Нужно переделывать. Совсем без реализации - сообщение "Ошибка OLE" от 1С...
С результатами теста немного поторопился, IDispatchEx существует, нужно сделать и посмотреть, что к чему...
IDispatchEx запрашивается, но никак не используется. Так что его делать рано.
Появилась заглушка для IDispatchEx. Только вот 1ска её всё-таки игнорирует - запрашивает, получает, а потом не использует.
Возможно стоит задуматься о использовании midl, а не widl....поможет решить ряд проблем, таких как параметр lcid и раннее и позднее связывание меньшими затратами. А если еще ее написать на плюсах, то будет быстрее ( в смысле времени на разработку ).
Откладываем, bugs@ в ближайшее время делать ничего не будет.
Задача относится к релизу 2.1. , который больше не поддерживается. Аннулирую.
