Здравствуйте !
Не могу определить область в которой у меня "недопонимание" (С,  Builder или Native, а  может и все вместе . 
Решила, что поместив в "для новичков" точно не ошибусь 
Имеем C++ Builder и следующую процедуру:

Все работает, пока мы не меняем настройки CodeGuard
После включения опции "All CodeGuard options on"
NtCreateFile выдает STATUS_DATATYPE_MISALIGNMENT (Invalid access to memory location)
Nt - описание:
// Alignment Fault
// A datatype misalignment was detected in a load or store instruction.
//...winnt #define STATUS_DATATYPE_MISALIGNMENT     ((NTSTATUS)0x80000002L)
Насколько я понимаю, требуется выравнивание на 32 битную границу.
Но assert`ы не срабатывают. Значит передаем, вроде правильно...

Соответственно, появляются два вопроса:
Почему так происходит ?
Как с этим бороться ? (Отключение CodeGuard`а считаю недостойным решением 

попробуй поиграться параметрами Data Aligment на вкладке "Advanced compile". Билдера под рукой нет, проверить не могу, но есть ощущение, что структуру OBJECT_ATTRIBUTES надо выравнивать как-то...   

Ух ты, какая полезная "вкладка" 
Но она не помогла   
Я еще пока плаваю во всяких директивах компилятору.
Может быть такое, что с ними я напартачила в одном юните, а аукается это в другом ?

еще билдер вроде как поддерживает директиву #pragma

Докопалась до вот этого:
В одном из юнитов (не в том где вызывается наша процедура) есть такие строчки:


Если их закоментировать, то проекту становиться глубоко чихать на настройки CodeGuard.
Знай себе работает и не пискает 
Если же их "открыть", то работаем только с отключенным CodeGuard (ошибка описана выше).

Объясните, пожалуйста, что крамольного в таком объявлении
и как эта крамола влияет на работу ?

Riply, ну если представить себя препроцессором и обработать эти строчки, то получится, что переменной NtDll_LibNameU присваивается набор значений, в частности, два числа и указатель на строку. А так как объявления UNICODE_STRING нет, то нельзя сделать вывод, что это за структура такая...

В принципе, это штатная DDK-шная структура для работы с юникодными функциямиДругое дело, что сложно представить где объявление, используемое даже для написания драйверов kernel-mode, может аукнуться в обычном приложении.  
Как влияет - ты уже выснила  Крамольного, в принципе, ничего не вижу, но к примеру, где-нить может стоять директива типа такой:в которой CodeGuard в зависимости от этой декларации использует разные вызовы... Ввиду того, что неизвестно, какие хедеры\либы ты в своем проекте подключала, а самому сымитировать проблему не получилось, предположить что-либо более правдоподобное сложно 

"сымитировать проблему" очень просто.
Прежде чем утверждать, что влияют именно эти строчки, я попробовала исключить 
все возможные собственные ляпы следующим образом:
1. Создала новый пустой проект (WindowsFormApplication) C++Builder 2006
2. Нашла и скопировала в него код из http://forum.vingrad.ru/index.php?showtopic=180900&view=findpost&p=1310202
    (некоторым он должен быть очень знаком   )
3. Добавила туда #include <winternl.h> и эти две строчки
4. Включила CodeGuard + в Tools->CodeGuard Configuration включила Append to log file

Вот и все: наблюдаю этот эффект   


Это некузявый вариант. Хорошо что данная вещь проявилась с помощью CodeGuard.
Где гарантии, что она не аукнется в другое время и в другом месте ?
Ведь истинные причины и механизм сбоя я до сих пор понять не сумела  

Добавлено через 8 минут и 22 секунды


Попробовала (хотя мне ой как далеко до него   )
и с удивлением обнаружила, что ULONG(NtDll_LibNameU.Buffer) выражается аж нечетным числом.
Сейчас пытаюсь понять: это я ничего не смыслю в указателях из С или данный дефайн,
действительно никуда не годится 

Riply, то, что buffer выражается нечетным числом, это не криминал. Это же указатель.

"Как прикажешь тебя понимать, Саид ?" (с)
Насколько, я понимаю, криминал да еще и какой 
Во всяком случае, ни одна из тех Nt-функций, на которых я проверяла, 
не переваривала "нечетный" Buffer в имени. (Хотя для забраковки метода достаточно, чтобы ругалась всего одна)
Впрочем, это легко проверить, инициализировав UNICODE_STRING вручную и передав в любую понравившуюся Nt-ф-ию.
Меня удивляет другое: то что мы получаем такой буфер этим "дефайном" и его влияние на "код в целом".

Может кому интересно. Вот маленький отчет:
Наш дефайн не виновен и полностью оправдан.
Тяжким бременем обвинения ложатся либо на Builder, либо на CodeGuard    
Опыты показали следующее:

Данный вариант работает при любых настройках CodeGuard.
Но стоит раскоментировать первую строчку (не трогая вторую), и при включенном CodeGuard 
получаем "нечетный" Buffer и нецензурщину от NtCreateFile.
Причем не важно используем ли мы RTL_CONSTANT_STRING или расписываем его на месте вручную.
Эффект тот же. Т.е. данный способ декларации так влияет на инициализацию TestFile,
что не спасает даже последующая попытка использовать RtlInitUnicodeString.

P.S. Понимаю, что меня сейчас растерзают на месте, но скажу: Delphi себе таких шуток не позволяет 

Riply, повторяю, нечетный указатель это не криминал.
Если хочешь проверить, сделай:Или buffer будет нечетным или p. И от этого ты никуда не денешься.

Sorry, это я плохо излагаю свои мысли.
Я имела ввиду, что такая инициализация нашего Buffer`а, это криминал, как минимум, 
для нашего конкретного случая (аккуратно выражаясь), 
а скорее всего, это криминал для любой Nt-функции, принимающей на входе UNICODE_STRING.


Вот осторожность этой фразы меня и удивляет.
Ибо (при данном коде) я бы утверждала, что p будет нечетным, а buffer бутед выровнен на 32-битную границу,
а под BDS 2006 и выше на 64-битную. (Извращенные настройки среды мы не рассматриваем   )

я стараюсь быть осторожным   

Слава богу ! А то я уж испугалась, что данный код может возвращать "неровный" указатель 

Ну вот. После того, как мы выяснили с какими неприятностями мы можем столкнутся,
встает несколько вопросов:
Как объявлять константы типа UNICODE_STRING, чтобы
 они сами были выровнены как минимум на 32-х битную границу
 и чтобы Buffer был выровнен как минимум на 32-х битную границу.
 Причем, чтобы это не зависило от внешних факторов (типа включения/выключения CodeGuard)
 и не влияло не остальной код ?

Второй вопрос:
есть у меня некая струтура. Код привожу на Delphi, ибо изясняясь только на этом языке (пока еще)
я могу быть уверена, что сказала именно то, что хотела сказать 

Констант типа SysClassGuid_DiskDrive у меня как собак нерезанных 
Как, соблюдая условия, описанные для UNICODE_STRING, инициализировать их ?
Причем сам _Guid должен быть выровнен как минимум на 64-х битную границу.
И можно ли инициализировать константу GUID строкой, как в Delphi
или мне вручную придется переводить строки типа '{4d36e967-e325-11ce-bfc1-08002be10318}'
в числовые значения ?

P.S. 
 Я не стала выносить вопрос по инициализаци чистого GUID в отдельную ветку, т.к.
 он неразрывно связан с выравниванием.