Description: OS Win7 SP1 x64, LibreOffice 5.3.4.2 x64, Writer, session is complete, documents are saved, in %TEMP% is a temporary directory TEMP%\hsperfdata_%USERNAME% with a file of 64k size whose name ($PID) is always the same as the process PID openoffice.bin. We try to delete it by any file manager - file %TEMP%\hsperfdata_%USERNAME%\$PID is locked. Call Process Hacker of any branch 2.x / 3.x (for example v3.0.5305.778 DEV), press Ctrl-F1 (Find Handles or DLL) in the opened search dialog, insert $ PID, Enter - see the list of the handles, then in the list Press Ctrl-A-> Del-> Close-> Ctrl-F-> Enter get a residual list of not closed handles, Ctrl-A-> Del-> drop openoffice.bin with the exception of c000070a in ntdll.dll and msvcr1 * 0.dll . Call the debugger, we see its message that the exception occurred in openoffice.bin, but its thread ended with code 0x0: http://s018.radikal.ru/i511/1707/88/be0c9ce438ef.png http://s61.radikal.ru/i174/1707/7b/f29ba0fe2ba8.png http://s41.radikal.ru/i094/1707/09/8f81142c66dc.png http://s11.radikal.ru/i183/1707/6d/5977bac016a8.png Steps to Reproduce: 1. Open %TEMP% and try delete %TEMP%\hsperfdata_%USERNAME% 2. Call Process Hacker of any branch 2.x/3.x (for example I use v3.0.5305.778 DEV - https://yadi.sk/d/193Gnglm4Ia5D is permanent link for my personal build), press Ctrl-F1 (Find Handles or DLL) in the opened search dialog, insert %TEMP%\hsperfdata_%USERNAME%, Enter - see the list of all opened the handles for this dir, then in the list press button Ctrl-A -> Del -> Close -> Ctrl-F-> Enter for get a residual list of not closed handles, again Ctrl-A -> Del -> and crash openoffice.bin with the exception of c000070a in to lib ntdll.dll and msvcr1 * 0.dll . Call the debugger, we see its message that the exception occurred in openoffice.bin, but its thread ended with code 0x0: http://s018.radikal.ru/i511/1707/88/be0c9ce438ef.png http://s61.radikal.ru/i174/1707/7b/f29ba0fe2ba8.png http://s41.radikal.ru/i094/1707/09/8f81142c66dc.png http://s11.radikal.ru/i183/1707/6d/5977bac016a8.png Actual Results: Crash on some scenarios then close handles and visual - don't delete hsperfdata_%USERNAME% Expected Results: Delete hsperfdata_%USERNAME% after close file and not crash openoffice.bin then user close all handles for hsperfdata_%USERNAME%/* . Reproducible: Always User Profile Reset: None, user profile not resetting Additional Info: I repeated the experiment again, but through the File unlock v3.6.0.4040 plug-in to Far Manager 3.0 (the plug-in searches for and removes the locked files and forcibly closes them, the plug-in is based on the code of the incoming Process Hacker driver KProcessHacker.sys v2.x) The first time the plugin found the openoffice.bin handles, output the request, after correctly closed all the handles and openoffice.bin did not fall. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
well what do you expect to happen if you mess around with process state with a debugger and make random changes? > Expected Results: > Delete hsperfdata_%USERNAME% after close file and not crash openoffice.bin then > user close all handles for hsperfdata_%USERNAME%/* . i'm afraid your expectations are a bit unrealistic, if you file a bug at the OpenJDK project (which is what creates that file) you'll find that Santa won't bring you this pony.