Столкнулся со странной проблемой - на XP (было проверенно несколько машин) LoadLibraryA и LoadLibraryW работают нормально (ясно что во вторую я передаю юникод строку), но на Win7 (опять же несколько машин) вторая возращает 0. Код (Text): invoke LoadLibrary*, _sLibName* _sLibName* db "MyLib.dll", 00h _sLibName* du "MyLib.dll", 00h Код выглядел примерно как то так. Пока поставил ascii вариант, Но меня попросили переделать что бы работало и не по относительным путям. Никто не сталкивался?
Вы даете такие ссылки, как будто пол часика порыться в интернетах сложнее, чем отпостить на форуме и днями дожидаться ответа. Правда сервис понравился, возьму на заметку. Да я искал, но подобной проблемы не нашел. Осложнение в том, что у меня самого XP, и запуститься из под отладчика я не могу. Сейчас накидал пример, попробую погоняться за товарищами, как у них пройдет такой трю не с моей *.dll, а с каким либо user32.
00h Следующий код будет возвращать ERROR_NOACCESS: Код (Text): Local Variable[2]:BYTE push offset $DllName Call LoadLibraryA В чём же фишка
У меня эту ошибку возвращало когда был C0000005 в длл_мейн. Мб крешится где-то по ходу загрузки длл-ки, вот тока что читал,чел решил эту проблему используя другой компилер. Выложи длл-ку. Кстати закономерности крешей на x86,x64 нету?
Похоже я нашел ошибку, в одном из возвратов DllEntryPointa стоял место retn 0ch просто retn. Странно, что оно работал вообще) Ну с другой стороны могу предположить, что в ХР и ascii варианте в Win7 не затрагивало какие либо локалки и т.д. Сейчас исправлю, поймалю людей для теста и отпишусь.
00h >но на Win7 (опять же несколько машин) вторая возращает 0 Для dll без пути лоадер сначала пытается открыть секцию с соответсвующим именем ("MyLib.dll", с хендлом RootDirectory == "\KnownDlls[32]"): Код (Text): 0:000> k ChildEBP RetAddr 000cfc5c 77a9d45a ntdll!NtOpenSection 000cfc90 77a9c3d8 ntdll!LdrpFindKnownDll+0x88 000cfd80 77a9c305 ntdll!LdrpFindOrMapDll+0x18d 000cff00 77a9c116 ntdll!LdrpLoadDll+0x2b2 000cff34 76c81d2a ntdll!LdrLoadDll+0x92 000cff6c 76991e23 KERNELBASE!LoadLibraryExW+0x178 000cff80 00401099 kernel32!LoadLibraryW+0x11 Обыкновенно для пользовательских dll здесь должен быть возвращён STATUS_OBJECT_NAME_NOT_FOUND – далее для него сделан специальный кейс для продолжения загрузки. Однако ты передаёшь невыровненную на 2 юникодную строку и возвращается STATUS_DATATYPE_MISALIGNMENT. Вот и всё.
Sol_Ksacap Ага, смотрим в generr.c соответствия: Код (Text): STATUS_DATATYPE_MISALIGNMENT, ERROR_NOACCESS, STATUS_ACCESS_VIOLATION, ERROR_NOACCESS, STATUS_DATATYPE_MISALIGNMENT_ERROR, ERROR_NOACCESS, Просто RtlNtStatusToDosError() конвертит разные нэйтивные коды ошибок в один винапишный.
Черт, да, ошибка была моя - в одном из возвратов из DllEntryPoint возращало 0, а не 12. Сбило с толку то, что это работало на XP и 7 в асковом варианте. Извиняюсь за некоректную тему. Вопрос закрыт.
00h Нет, подожди. Код (Text): 0:000> k8 # ChildEBP RetAddr 00 0028e5b8 77a997c0 WINBRAND!_DllMainCRTStartup 01 0028e5d8 77a9d749 ntdll!LdrpCallInitRoutine+0x14 02 0028e6cc 77a9d60c ntdll!LdrpRunInitializeRoutines+0x26f 03 0028e838 77a9c116 ntdll!LdrpLoadDll+0x4d1 04 0028e86c 76c81d2a ntdll!LdrLoadDll+0x92 05 0028e8a4 76c81d7a KERNELBASE!LoadLibraryExW+0x178 06 0028e8c4 75c7a27e KERNELBASE!LoadLibraryExA+0x26 07 0028e910 75cc7de2 SHELL32!__delayLoadHelper2+0x59 0:000> uf LdrpCallInitRoutine ntdll!LdrpCallInitRoutine: 77a997ac push ebp 77a997ad mov ebp,esp 77a997af push esi 77a997b0 push edi 77a997b1 push ebx 77a997b2 mov esi,esp 77a997b4 push dword ptr [ebp+14h] 77a997b7 push dword ptr [ebp+10h] 77a997ba push dword ptr [ebp+0Ch] 77a997bd call dword ptr [ebp+8] 77a997c0 mov esp,esi ; <-- 77a997c2 pop ebx 77a997c3 pop edi 77a997c4 pop esi 77a997c5 pop ebp 77a997c6 ret 10h Как можно видеть, в соблюдение конвенций вызова 7ка особо не верит и восстанавливает esp после вызова. Так что вопрос пока открыт. (И тема корректна).
Так, интересно. Ну во-превых оно теперь работает нормально (когда я подправил срез стека). С другой стороны я так понимаю юникод от аксии отличается только процедурой, подготовливающей строку (по крайней мере на хр). Может ли быть фейл от невыровненной юникод строки? (я столкнулся с этим при чтении из реестра, RegOpenKeyEx в часности)
>Может ли быть фейл от невыровненной юникод строки? Да, может. В #10 показано, где может обрываться загрузка при передаче невыровненной строки в LoadLibraryW(). Но ведь размер "retn" отличается от размера "ret 0Ch" на чётное число байт – это ведь не должно было повлиять на баланс выравнивания последующих строк?
Я не только это менял в коде - смещение как раз может быть любое. А вообще я не понял, зачем винде выравненные юникод строки.
