>> Tracing execution of emacs with Process Explorer shows that the temp
>> file used to native compile trampolines is opened and closed repeatedly
>> by emacs, and at the point of the backtrace is still open by the same
>> emacs process.
>
> We need to know which code opened it the last time and didn't close
> it.  Can you figure that out?  All the files Emacs opens go through 2
> functions in w32.c: sys_fopen and sys_open, so by running with 2
> breakpoints there that show the backtrace and continue, you should be
> able to see the culprit, and we can then take it from there.

As noted above, I think it is the code in native-elisp-load interacting
woth the way that the files are renamed (and if those operations have
specified posix semantics or not). 

>> I am not sure excactly when this issue started, but I did not see it in
>> emacs-29 or master bootstrapped before this month.
>
> Could be because we now compile trampolines differently (to avoid the
> danger of the "fork bomb" due to recursive compilation of
> trampolines by async subprocesses).

Any idea when those changes were committed, and which changesets ? IT
doesn't apper obvios from the commit history.

> Andrea, any suggestions or comments?
>
> Thanks.