[programmer.cpp1986]

Thanks EP_X0FF, my fault was from not using "KeStackAttachProcess" :)

[Dmitry Varshavsky]

PSYSTEM_HANDLE_INFORMATION Info;
DbgPrint("%wZ", &FileObject->FileName); ===> I got the access violation at this line of my code...

It seems that either FileObject or FileObject->FileName.Buffer is NULL, do something like

Code: Select all

if (FileObject && FileObject->FileName.Buffer && FileObject->FileName.Length > 0) DbgPrint("%wZ", &FileObject->FileName);

At least you shouldn't see BSODs anymore, but for further investigation you need to watch what yours variables contain through code flow, use WinDbg to debug your driver.

Despite the fact that in most cases FileObject -> FileName field contain plausible value, generally you can't rely on this value. Filename is valid only during IRP_MJ_CREATE operation. Yes, some simple FS drivers, such as cdfs, directly deal with this value ( see wdk src, \src\filesys\cdfs\Win7\fileinfo.c ) but it's not a rule. Fastfat ( src are also available in wdk ), Ntfs and especially network fs uses proprietary data stored in file control block to obtain a file name. Several times I've faced the situation when FileObject->FileName field was a complete trash, which cannot be avoided with simple zero check, so you sometimes will have a random BSODs on this code.
The correct and the simpliest way was already suggested - use ObQueryNameString. You can also compose IRP_MJ_QUERY_INFORMATION/FileNameInformation request by yourself, which is also good, but you have to handle volume name separately. Or you may dig out FsContext/FsContex2 content for common fs drivers :roll: