R>советую по чаще пользоваться дебагером что бы знать не только теорию но и практику
R>в процессе работы винда может двигать модули
R>до введения ASLR этих движений не было по моим наблюдениям
Винда не может двигать уже загруженный модуль. ASLR влияет на базу загрузки модуля, после загрузки — все остается где было до выгрузки. Если у вас изза включения ASLR для дллки чтото начинает глючить, значит или у вас гдето есть чтото типа:

DLL = LoadLibrary("foo.dll");
SomeFunction = GetProcAddress(DLL, "SomeFunction");
..blablabla...
FreeLibrary(DLL)
DLL = LoadLibrary("foo.dll");
..blablabla...
SomeFunction()

В этом случае на последней строчке с включенным ASLR вероятность крэша на много порядков выше чем с выключенным. Но, всеже, с выключенным она тоже будет ненулевая.

Или же у вас код который не умеет толком работать с void *, например

DLL = LoadLibrary("foo.dll");
int CastedPointer = (int)GetProcAddress(DLL, "SomeFunction");
...
SomeFunctionT SomeFunction = (SomeFunctionT)CastedPointer;
SomeFunction();

в этом случае тоже вероятность свалиься с ASLR сильно выше чем без оного. Потому что с ASLR вероятность того что модуль загрузится выше первых 4 гиг очень высока (оно вроде вообще только туда и грузит ASLR'ед дллки), а без оного — система попытается промапить модуль по его preferred base. Что обычно находится в нижних адресах.
А тайпкаст в 32х битную переменную (int) ломает поинтеры указываюшие выше 4 гиг.


Но в данном случае имеем дело не с длл, а с апликухой, в которой даже релоков нет. И вероятно это в самом деле баг загрузчика, т.к. такие минималистичные апликухи нынче редкость, а микрософт индусами полнится.

R>советую по чаще пользоваться дебагером что бы знать не только теорию но и практику
R>в процессе работы винда может двигать модули
R>до введения ASLR этих движений не было по моим наблюдениям
Винда не может двигать уже загруженный модуль. ASLR влияет на базу загрузки модуля, после загрузки — все остается где было до выгрузки. Если у вас изза включения ASLR для дллки чтото начинает глючить, значит или у вас гдето есть чтото типа:

DLL = LoadLibrary("foo.dll");
SomeFunction = GetProcAddress(DLL, "SomeFunction");
..blablabla...
FreeLibrary(DLL)
DLL = LoadLibrary("foo.dll");
..blablabla...
SomeFunction()

В этом случае на последней строчке с включенным ASLR вероятность крэша на много порядков выше чем с выключенным. Но, всеже, с выключенным она тоже будет ненулевая.

Или же у вас код который не умеет толком работать с void *, например

DLL = LoadLibrary("foo.dll");
int CastedPointer = (int)GetProcAddress(DLL, "SomeFunction");
...
SomeFunctionT SomeFunction = (SomeFunctionT)CastedPointer;
SomeFunction();

в этом случае тоже вероятность свалиься с ASLR сильно выше чем без оного. Потому что с ASLR вероятность того что модуль загрузится выше первых 4 гиг очень высока (оно вроде вообще только туда и грузит ASLR'ед дллки), а без оного — система попытается промапить модуль по его preferred base. Что обычно находится в нижних адресах.
А тайпкаст в 32х битную переменную (int) ломает поинтеры указываюшие выше 4 гиг.


Но в данном случае имеем дело не с длл, а с апликухой, в которой даже релоков нет. И вероятно это в самом деле баг загрузчика, т.к. такие минималистичные апликухи нынче редкость, а микрософт индусами полнится. Или же у ТС троянчик сидит, или антивирь. С глючным инжектором. Потому хотелось бы увидеть лог windbg о том какие длл в процесс и в каком порядке загружаются.