If you run an help file from mIRC, for example ircintro.chm, then close that help file, mIRC keeps the file locked (you can't delete the file) if the mIRC help file mirc.chm is still running.

1) run the mIRC help file mirc.chm
2) run ircintro.chm (/ircintro)
3) close ircintro.chm
4) try to delete the file ircintro.chm in the mIRC folder (/run .), explorer says the file is open in mIRC
5) close mirc.chm
6) you can now delete the file in explorer

Thanks for your bug report. This has been discussed before. mIRC passes the help file name to the Windows Help system which is performing its own lock on the file until the calling application exits. mIRC has no control over this.

Ok, well in this report the file being locked is not the file being used (though indeed, it's not related the the mIRC help file specifically).
You say the application needs to exit to release the file but closing all help files opened from mIRC is sufficient.

This is not for mIRC's own help file but to handle my own custom help file. CHM file are blocked by default, they need to be unblocked, which is not great for sharing and widespreading. One way around the block is to download the file manually from mIRC ($urlget works).
So I wrote a small code which updates the help file from an http server, but this issue prevent me from updating if any other help file (typically the mIRC help file) is still open.

Googling this issue does not give any result. Or could it be that you need to release resources when we close an help file or something?

Is it possible to extend the /winhelp command to take new parameters/switches, which could be used to close the help file, aka "/winhelp -c <name>" and "/winhelp -n name file topic", so that at least script can handle this situation better? Maybe a $winhelp identifier as well to know what's open.

I'm afraid there is no way around it - this has been looked into before, several times. The file is locked by the Windows Help system until the application exits regardless of what the application does.

Alright, thanks for the answer. I really don't understand this design from Windows

As far as I know, it is due to a bug with how Windows handles HH_HELP_CONTEXT context-based lookups.

You can find a technical explanation here, where it also describes how to get around it - by decompiling the CHM file using the ITStorage COM interface, mapping context ids to topic links, and then using HH_DISPLAY_TOPIC to display the topic instead.

I generally prefer to avoid using barely documented COM interfaces - this one has so few google hits that it might as well not exist. And decompiling a CHM seems a little over-the-top for just opening a help file :-) But I have implemented a minimal version and it seems to work fine on XP through to Windows 11, so I am going to add it to the next beta. It will need to be tested on a variety of CHM files to make sure it's okay.

Great news, thanks for looking into it.