Thanks EP_X0FF, my fault was from not using "KeStackAttachProcess" :)
iSecure wrote: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.programmer.cpp1986 wrote:PSYSTEM_HANDLE_INFORMATION Info;It seems that either FileObject or FileObject->FileName.Buffer is NULL, do something like
DbgPrint("%wZ", &FileObject->FileName); ===> I got the access violation at this line of my code...Code: Select allAt 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.if (FileObject && FileObject->FileName.Buffer && FileObject->FileName.Length > 0) DbgPrint("%wZ", &FileObject->FileName);
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: