winwaed
16th November 2006 21:01 UTC

Cannot find nsub.tmp?
I've been using NSIS for some of our applications for a couple of years now.

I occasionally get reports of it requesting a reboot and then Windows saying it can't find a temporary file. Everything is okay after that.
Unfortunately I can't reproduce the problem.
Today, a new customer reported the actual message: "Windows cannot open this file nsub.tmp"

This occurs when Windows restarts.

The application is a VB6 DLL (add-in for an MS application), but the installer also includes the VB6 runtimes (code taken from the Appendix) and a third party DLL.

I assume the reboot is required because one of the DLLs is already loaded in memory?

But what is causing the error? What is nsub.tmp? Has anyone seen anything like this before? What should I look for in the NSIS script?

I didn't want to post the entire script with a "where's my bug" question, but I can post bits or the entire thing if it will prove useful...

Richard

goldy1064
16th November 2006 21:31 UTC

nsub.tmp sounds like the name of the $PLUGINSDIR folder. If you are trying to re-run an installer after restart that references that tmp directory, that could cause the failure as the PLUGINSDIR directory is removed when the installer exits.

kichik
17th November 2006 11:57 UTC

It most likely means the file set to automatically register the DLL files after reboot was deleted. That file should be located along with the DLL files themselves, so deleting the temporary directory on reboot shouldn't bother it. However, you should still ask your user if he does that. Also have him try and disable the anti-virus.

Besides that, post the part of the script where the DLL files are installed, any other InstallLib calls you might have there and the version of NSIS you've used to create the installer. Maybe there's something in the script.

winwaed
17th November 2006 21:13 UTC

Finding the NSIS version will take some time - it was built on my old dev machine which I retired from front-line work last week. It will still be installed on it, but it isn't connected up. I'm guessing it was about 12-18months old.
I installed the latest&greatest for this PC here.

If I understand it correctly, I'm only registering my own DLL. Here are the DLL installation extracts.


; DLL stuff for VB6
!include "UpgradeDLL.nsh"
!define VBFILESDIR "VB_DLLs" ; Location of VB6 runtime files


Section "MainSection" SEC01

; stuff deleted here - list of files and menu shortcuts, registry writes,etc

File "MileCharter.dll"
RegDLL $INSTDIR\MileCharter.dll
SectionEnd

Section "Install VB DLLs"
!insertmacro UpgradeDLL ${VBFILESDIR}\Comcat.dll $SYSDIR\Comcat.dll $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\Msvbvm60.dll $SYSDIR\Msvbvm60.dll $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\Oleaut32.dll $SYSDIR\Oleaut32.dll $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\Olepro32.dll $SYSDIR\Olepro32.dll $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\ArmAccess.dll $SYSDIR\ArmAccess.dll $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\Comdlg32.ocx $SYSDIR\Comdlg32.ocx $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\mscomctl.ocx $SYSDIR\mscomctl.ocx $SYSDIR
!define UPGRADEDLL_NOREGISTER
!insertmacro UpgradeDLL ${VBFILESDIR}\Asycfilt.dll $SYSDIR\Asycfilt.dll $SYSDIR
!insertmacro UpgradeDLL ${VBFILESDIR}\Stdole2.tlb $SYSDIR\Stdole2.tlb $SYSDIR
!undef UPGRADEDLL_NOREGISTER
; Only lease DLL count on new installation
IfFileExists $INSTDIR\MileCharter.dll skipAddSharedDLL
Push $SYSDIR\Comdlg32.ocx
Call AddSharedDLL
Push $SYSDIR\mscomctl.ocx
Call AddSharedDLL
Push $SYSDIR\ArmAccess.dll
Call AddSharedDLL
Push $SYSDIR\Asycfilt.dll
Call AddSharedDLL
Push $SYSDIR\Comcat.dll
Call AddSharedDLL
Push $SYSDIR\Msvbm60.dll
Call AddSharedDLL
Push $SYSDIR\Oleaut32.dll
Call AddSharedDLL
Push $SYSDIR\Olepro32.dll
Call AddSharedDLL
Push $SYSDIR\Stdole2.tlb
Call AddSharedDLL
skipAddSharedDLL:
SectionEnd


Function AddSharedDLL
Exch $R1
Push $R0
ReadRegDword $R0 HKLM Software\Microsoft\Windows\CurrentVersion\SharedDLLs $R1
IntOp $R0 $R0 + 1
WriteRegDWORD HKLM Software\Microsoft\Windows\CurrentVersion\SharedDLLs $R1 $R0
Pop $R0
Pop $R1
FunctionEnd

Function un.DecrementSharedDLL
Exch $R1
Push $R0
ReadRegDword $R0 HKLM Software\Microsoft\Windows\CurrentVersion\SharedDLLs $R1
StrCmp $R0 "" done
IntOp $R0 $R0 - 1
IntCmp $R0 0 rk rk uk
rk:
DeleteRegValue HKLM Software\Microsoft\Windows\CurrentVersion\SharedDLLs $R1
Goto done
uk:
WriteRegDWORD HKLM Software\Microsoft\Windows\CurrentVersion\SharedDLLs $R1 $R0
done:
Pop $R0
Pop $R1
FunctionEnd

winwaed
17th November 2006 21:16 UTC

I should also add that I am not doing anything explicitly for a reboot. Or doing anything to handle a reboot, for that matter.

NSIS must be detecting that a reboot is required on its own (I assume something is in use).


Richard

kichik
18th November 2006 11:14 UTC

Well, that was pretty easy to reproduce. I just installed RouterWriter.exe and got this message. It's because the RegTool was extracted without the .exe extension and Windows didn't know how to execute it. Simply upgrade to the latest version of NSIS, use Library and you're set.

winwaed
18th November 2006 14:14 UTC

Thanks - yes RouteWriter's installation script was copied from MileCharter so it will have the same problem.

So "insertmacro InstallLib" replaces the UpgradeDLL that I had?
And it looks like I no longer need the Add/Decrement DLL code?
That will simplify things :-)


btw, Thanks for everyone's help.


Richard

kichik
18th November 2006 14:17 UTC

Yes, InstallLib completely replaces UpgradeDLL, including the shared reference count handlers.

winwaed
18th November 2006 14:26 UTC

Excellent! That does simplify things. I'll try it out this weekend - I have to build a new version for the same customer (to fix an unrelated bug).

I already have the latest NSIS installed - I installed it when I built my new dev machine last week. (my old dev PC must have been a bit old - this Core2Duo screams :-) )

Thanks everyone!

Richard

winwaed
19th November 2006 21:02 UTC

Although I had problems reproducing the problem, initial tests of the rebuilt installation exe look good. I'll be passing it to the customer on Monday.

Also the new DLL installation script bits are much better looking and cleaner - an improvement that I definitely appreciate.

Thanks!

Richard

kichik
21st November 2006 18:20 UTC

You have to have an older version of one of the DLL files installed to reproduce this. On a new installation, XP apparently has an older version of MSVBVM60.dll.