Вопрос собственно для автора :) или может кто встречался с подобным. В разделе FileWorks есть пример работы с файлами. Драйвер работает нормально. Мною был создан драйвер, который принимает от запускающей программы в буфере UNICODE строку с именем файла и открывает его. Но есть один глюк - если файл находится в папке (даже с русским именем), то файл окрывается без вопросов, если файл находится в корне диска (у меня один "C:"), то ошибка 0C0000034h - STATUS_OBJECT_NAME_NOT_FOUND :(
Переделал исходник FileWorks.bat - все работает и система "дышит" равномерно.
При передаче имени файла использую
invoke MultiByteToWideChar, CP_ACP, 0, addr BufFileName, eax, edx, 1024
В драйвере вызываю

...
LOCAL pusFileOpenName	:UNICODE_STRING
LOCAL status		:NTSTATUS
LOCAL iosb		:IO_STATUS_BLOCK
LOCAL oa		:OBJECT_ATTRIBUTES

	mov status, STATUS_UNSUCCESSFUL
	assume esi:ptr _IRP
	mov esi, pIrp
	invoke RtlInitUnicodeString, addr pusFileOpenName, [esi].AssociatedIrp.SystemBuffer
	.if eax==STATUS_SUCCESS
		lea ecx, oa
		InitializeObjectAttributes ecx, addr pusFileOpenName, OBJ_CASE_INSENSITIVE \
             + OBJ_KERNEL_HANDLE, NULL, NULL
		invoke ZwCreateFile, addr hDiskFile, FILE_READ_DATA + \
            FILE_WRITE_DATA, addr oa, addr iosb, 0, \
            FILE_ATTRIBUTE_NORMAL, 0, FILE_OPEN, \
            FILE_SYNCHRONOUS_IO_NONALERT or \
            FILE_NON_DIRECTORY_FILE or FILE_RANDOM_ACCESS \
            or FILE_NO_INTERMEDIATE_BUFFERING, NULL, 0
		mov status, eax

В eax=0C0000034h

В корне или в каталоге файл, принципиальной разницы нет. Что у тебя в pusFileOpenName.Buffer после RtlInitUnicodeString?

Ксати, RtlInitUnicodeString ничего не возвращает. Так что проверять на STATUS_SUCCESS даже вредно.

Да, сам глючу... в pusFileOpenName.Buffer в конце имени файла мусор вместо 2-х нулей. Вот так, паришься 2 часа и ходишь вокруг, да не туда.
Еще вопрос по KmdKit. После установки перестал компилиться драйвер :( выдает ошибки, что того нет, этого нет... В чем проблема нашел - перемещены управляющие коды типа IOCTL_DISK_GET_LENGTH_INFO. В будущих версиях тоже будут перестановки ? А то опять искать... Ж;)

Никаких глобальных перестановок не намечается. Ну если я только что-нить случайно не порушу ;)

Касательно IOCTL_DISK_GET_LENGTH_INFO, если я правильно помню, его никогда не было в \Include\w2k ибо он определяется только начиная с XP в ntdddisk.h. Так что в \Include\w2k\ntdddisk.inc его быть не должно. Этот код я использую только в \examples\advanced\RamDisk. Там лежит отдельный файлик xp+.inc, где он и определен. Подозреваю, что ты его оттуда вырипал и пихнул куда не надо, а на меня бочку катишь. Столько этих KmdKit'ов развелось уже, можно и запутаться :)

2Four-f:
На твоей странице лежит v. 1.7 а здесь 1.6.
Непорядок. :)

Просто пожелание.
Можно ли писать(whatsnew.txt или типа того),что изменилось от версии к версии? Не сразу понятно,чем отличается ramdisk v1.6 от 1.7 кроме размера.

:) Да припоминаю... Неправ был. Только я его вырипал еще раньше из ntdddisk.h

[ TheDeath: На твоей странице лежит v. 1.7 а здесь 1.6. Непорядок. :) ]

Это вопрос нескольких дней. К себе я его положил вчера. Вчера же послал мыл Aquila о том, что он там лежит + новую статью. Когда у Aquila появится время, он положит всё это на сайт. Вот и всё.


[ TheDeath: Можно ли писать(whatsnew.txt или типа того),что изменилось от версии к версии? Не сразу понятно,чем отличается ramdisk v1.6 от 1.7 кроме размера. ]

Это не так просто как кажется. Дело в том, что я и сам иногда не знаю что и чем отличается :) Вести какой-то постоянный мониторинг обновлений слишком геморройно. Но я постараюсь. Касательно ramdisk v1.6 vs 1.7 могу сказать точно - они ничем не отличаются ;) Размер разный потому, что в v1.6 я забыл удалить закоментаренный код.

Ещё добавлен IoctlDecoder v1.2 + кое-какие чисто косметические изменения. Причина по которой v1.7 вообще появилась в том, что я обнаружил один очень серьёзный баг в нескольких исходниках, а именно:

fastcall IofCompleteRequest, esi, IO_NO_INCREMENT

mov eax, [esi].IoStatus.Status

Так делать нельзя! Ибо вызывая IofCompleteRequest, мы говорим диспетчеру в/в, что типа всё - IRP завершен. После этого обращаться к IRP ни в коем случае нельзя. После после вызова IofCompleteRequest в IRP может быть, что угодно, в том числе и дырка. Этот баг проявляется только при очень большой нехватке памяти. Делать надо примерно так:

push [esi].IoStatus.Status
	
fastcall IofCompleteRequest, esi, IO_NO_INCREMENT

pop eax

Ну вот, вроде отчитался :)