Fri Jun 12 09:37:57 2020: Request 132811 was acted upon.
Transaction: Ticket created by ralf.neuba...@wido.bv.aok.de
Queue: PAR-Packer
Subject: Win32: Crash a week after start
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ralf.neuba...@wido.bv.aok.de
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=132811 >
Hi,
I just found out why PAR::Packer-generated executables tend to crash when I
interact with them after I started them some days ago and they stayed mostly
idle in the task bar -- this also happened on Win7, but I analyzed it under
Win10:
https://support.microsoft.com/en-us/help/4506040/temp-folder-with-logon-session-id-is-deleted-unexpectedly
You can imagine a program behaving strange or crashing when it wants to load
modules, resources or data files from its PAR_TEMP directory, but everything
but the already open DLLs has vanished. I don't know exactly which windows
versions are affected, but I don't want to give programs to users that suddenly
crash out of nowhere, they might lose trust into the programs.
I don't know if there can be a better solution than documenting this behaviour.
Of course one can set PAR_GLOBAL_TEMP or PAR_GLOBAL_TMPDIR, but you have to use
wrapper scripts or an installer that find a suitable directory on the user's
machine and set the variables for the process or globally -- which a bit
defeats the 'one executable, no installer, just double-click the file I gave
you' purpose of PAR::Packer. So the workaround I found is (without the
Win32API::File-doesn't-exist-on-non-Win32 handling):
if ('CODE' eq ref $INC[-1] && $^O eq 'MSWin32' && !$ENV{PAR_GLOBAL_TEMP} &&
!$ENV{PAR_GLOBAL_TMPDIR}) {
use File::Find;
use Win32API::File qw(:ALL);
#use threads;
#(async
{
no warnings 'File::Find';
find +{
no_chdir => 1,
wanted => sub {
# ignore result, handle stays open until program terminates
-f and createFile $_, 'r ke', 'rw';
},
}, $ENV{PAR_TEMP};
}
#)->detach;
}
Is there a better way?
Mit freundlichen Grüßen
Ralf
