-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update FLT_FILE_NAME_INFORMATION usage to match docs #1371
Conversation
This is possible a performance issue I've noticed on my system, where the `FMfn tag` pool is using increasingly more memory. It all seems be pointing to fltMgr.sys, which I guess is this `FltGetFileNameInformation` call. The code-path seems to be querying `FltGetFileNameInformation`, and on the success path, it only released the filename when the spool folder work is allowed. That meant this was effectively leaking a reference to `FLT_FILE_NAME_INFORMATION` for non-spooler work folders, because as the docs state: > After a successful call to FltGetFileNameInformation, the caller is responsible for releasing the pointer returned in the FileNameInformation parameter when the pointer is no longer needed. The caller does this by calling FltReleaseFileNameInformation.
great find will check it out on my system asap |
Yeah, over 2 days of usage, I ended up with a lot of pools leaked - validated via poolmon. There were also a lot of mapped memory file handle leaks of files that have only been open temporarily, so I suspect this is what caused it. |
Yea there are many old bugs in the sandboxie code base. |
It looks like this pull request may have stopped the ability to print inside sandboxes for some Chrome/Firefox users: #1376 (comment) |
hmm... not good because we should avoid memory leaks still |
My bad, fortunately this PR isn't involved in the printing issue. |
I was really confused how it would cause that, but did not know enough about the Sandboxie internals or FLT API to respond on that :D |
I really dont think its reaponsible, also when in roll back the change printing remains broken, so its somethign different |
I can confirm version 1.0.2 fixed the printing issue. |
This is possible a performance issue I've noticed on my system, where the
FMfn tag
pool is using increasingly more memory.It all seems be pointing to fltMgr.sys, which I guess is this
FltGetFileNameInformation
call.The code-path seems to be querying
FltGetFileNameInformation
, and on the success path, it only released the filename when the spool folder work is allowed.That meant this was effectively leaking a reference to
FLT_FILE_NAME_INFORMATION
for non-spooler work folders, because as the docs state: