DLL not registering -- Win7

[Chris]

Probably the same problem we discussed earlier this month (3 March?).
My installation appears to install without problem, but when I run the app it gives an error -- due to a DLL not being registered. (SB8 should register it).

If I manually register it using cmd box, regsvr32.exe ..... this succeeds (if I run it in elevated mode). And after that my app runs perfectly.

This installation gets shipped out to lots of people. About 1% seem to report this problem. Usually if they just repeat the installation a few times it does eventually work.

I'm thinking of supplying a batch file with the program for people to use to register the DLL after installation (no, only joking -- but that does seem a solution :-).

Any ideas??? SB8 attempts to register the DLL and (presumably) does not know it has failed. I do have a PC here where this occurs, so I can test anything you suggest.

[linder]

Chris,

It is not SetupBuilder that registers the DLL ;-) It is the DLL that registers itself and this fails. So you have to find out why this self-registration process fails on some machines ;-) Unfortunately, there is absolutely nothing SetupBuilder can do here. You can send me that DLL and I can try to debug it to see what might cause the failure in your DLL.

Friedrich

[Chris]

Further information.
PC is Win7 professional 64bit. My app is 32bit.

I have changed the setup script to add "Register DLLs Immediately" after each of the two DLLs of mine (instead of at the end "Register all pending...") I think this now makes it work OK.


Also: I have the DLLs, OCX, etc set to only install if version/date is older than existing. I try installing it several times (and restarting PC after). But still, EVERY TIME I get the message after completion that PC must be restarted to complete the install. Why?

I have tried turning UAC off. Turning all anti-virus/ security software off. No difference.

These problems only seem to apply to Win7 Pro 64bit.

[linder]

Chris,

Again, it is not caused by SetupBuilder ;)

But see this:

http://www.lindersoft.com/forums/showthread.php?p=73710#post73710

Perhaps this can help in your case. The latest SetupBuilder runtime calls OleInitialize() before it launches the registration process in the DLL. Some older/buggy DLLs need this call.

You can download the Development Build here:

http://www.lindersoft.com/downloads_licensed.htm

Friedrich

[linder]

But still, EVERY TIME I get the message after completion that PC must be restarted to complete the install. Why?

Because you replaced a locked (in-use) DLL. Not a good idea! Windows needs a reboot to replace the file.

You should check (before you continue with the real install) if your application is active.

Friedrich

[Chris]

Thanks Friedrich,

As far as I can see there is no In Use DLL. I restart the machine. None of my DLLs are loaded at startup. Check Task manager. Run SB8 Installer to install update (DLLs are set to check version/date). At the end Requires Restart.
(I do not restart. Try app. It runs fine).

Repeat all the above. At the end, Requires Restart.


Repeat all the above on a WinXP 32bit PC. Does not need to restart.

OK, I will do some more tests. Comment out DLLs one at a time and see if it is just one.
Just wondered if anything other than "DLL in use" could cause Windows to say Restart Required.??

[linder]

Chris,

In fact, it's very simple. If a file to be replaced is locked (in-use) then Windows needs a reboot. It only requests a reboot if the file can't be replaced because exclusive write access is not possible (file is locked/in-use).

You can very easily check this. If the reboot message comes up, simply check the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager->PendingFileRenameOperations

http://technet.microsoft.com/en-us/library/cc960241.aspx

There you'll find the file(s) that need(s) to be replaced at next reboot.

Hope this helps a bit.

Friedrich

[Chris]

Excellent, Thanks Friedrich.
(though I would point out that your "Very Simple" is for the rest of us humans = "possibly quite hard" :-) :-)


If SB8 is set to install a DLL, but check version/date. Could this trigger it to be Registered by the Register All Pending .... ?
ie. if it does not need to be replaced, does nothing happen, or does it still get registered??

[linder]

:) What I meant to say was "the explanation is simple" <g>.

If the installer does not replace the file and you have the "Register as OCX/DLL/EXE/TLB" Advanced option in the "File Properties" marked then the "Register all pending file operations" function will not execute the self-registration process in your DLL.

The one million dollar question is, why are files "locked" in your case. BTW, Task Manager can't be used to check if there are locked files. I would suggest to run the install and then at the end (when the install displays the reboot message, but before doing a reboot) check the registry key to find the names and location of the in-use files.

Friedrich

[linder]

BTW, if you are interested, you can send me the DLL and I'll test it here on our Windows machines (we have several clean Windows VMs in our office).

Friedrich

[Chris]

Done exactly what you suggested (while you were typing the suggestion :-)

Have checked: HKLM\System\CurrentControlSet...
HKLM\System\ControlSet001 and 002
HKLM\Software\Microsoft\CurrentVersion\RunOnce
and RunOnceEx
HKLM\Software\WOW6432Node\......\RunOnce

Although install ended with message System must be restarted....
None of the locations had any files pending. NO FILES PENDING.
The \PendingFileRenameOperations node is not there.

So.... ????

[Chris]

Forgot to say.... I have done this using the latest Development Build of SB8 that you suggested.

Happy to send you the DLL. errr. which one? :-)

[linder]

See attached screenshot. I have simulated a locked-file scenario for you on Windows 7 Ultimate x64. The file is in-use during the installation and so Windows needs a reboot. The Windows API writes the required information to the registry (elevated running setup).

Friedrich

[linder]

The one that does not register <g>. And you only need the Development Build if your self-registration DLL needs the additional OleInitialize() call.

If a locked file causes a reboot request then it is definitely logged in the registry (PendingFileRenameOperations value).

Friedrich

[linder]

NO FILES PENDING.
The \PendingFileRenameOperations node is not there.

So.... ????

There is no PendingFileRenameOperations "node". It's a value name under the "Session Manager" key name. And don't get confused with the empty "FileRenameOperations" key name ;)

Friedrich

[Chris]

I mean there is no PendingFileRenameOperation value name under the SessionManager Key.

[Chris]

Oops, I may need you to delete my last message to avoid me being thought of as stupid. I need to go and repeat the process.

[linder]

If there is no PendingFileRenameOperations value then the installer did not request a reboot to replace a locked file. The only other action that causes a reboot message is a "Reboot Operating System" script function in your project.

Friedrich

[linder]

Please do not delete it :) All this Windows UAC / x86 / x64 is very complex. It took us years to understand how it all works.

Friedrich

[Chris]

Thanks Friedrich,

I hereby declare that I did not properly read the helpful reply which did in fact point me at the right place. :-|

Anyway. The file that is pending is expsrv.dll (part of VBA DAO system).
In the SB8 Installation script it is set as Check Version/Date, and therefore should not need to be installed.

BUT... (maybe this is the problem).
Source file (to be installed): date: 02/14/2008 vers: 6.0.72.9590
Target file (already installed): 07/14/2009 vers: 6.0.72.9589
ie. Date newer but version older

Target file is already installed in both Win\System32\ and \sysWOW64\

Despite me having run the install a dozen times (and restarted), this file has NOT been replaced in either target location. But is shown as pending.

Maybe you can guess at what is getting confused.
(I probably do not need to install this file anyway -- historic reasons why it's there -- and also I will try changing source file Date to after 7/14/2009 to see if that fixes everything).

[linder]

Chris,

:)

You are not allowed to replace "expsrv.dll" because it is a file covered by Windows File Protection (WFP). OS Protected version is: 6.0.72.9589. You may need to update the operating system for this program to work correctly with package version: 6.0.72.9590. In other words, only a Windows update can replace this file. It shows as pending because the installer tried to overwrite it but it was locked (protected). Then Windows rebooted, replaced the file but WFP restored it to its original version.

Does this help?

Friedrich

[Chris]

I do not understand (yet) what is happening, but I have sorted out the original problem.

I've removed any mention of expsrv.dll from SB8 Install script. And deleted the Registry entry for PendingFileRenameOperations.
Then install again. This puts expsrv.dll back into the Pending... in the registry.
Also vbajet32.dll which is dependent on expsrv.dll.
Neither of these is mentioned in the install script so I do not know why they get put into the Registry as tmp files waiting to be renamed; every time I run the install.

Not a SB problem, but if you have any thoughts I'll be interested.

Thanks for the assistance and useful comments in this thread.

[linder]

Chris,

If you check the compiler .htm file, do you see any reference to expsrv.dll?

And do you install any "external" runtime component (e.g. a MS redistributable) from the installer?

Friedrich

[Chris]

>> Windows File Protection (WFP).........
>> only a Windows update can replace this file. It shows as pending because the installer tried to overwrite it but it was locked (protected). Then Windows rebooted, replaced the file but WFP restored it to its original version.

Many thanks. I think that explains all the odd and different results I've found on various computers and operating systems.

[linder]

You are welcome :)

Friedrich

[Chris]

One last question on this subject, sorry :-)

>> It shows as pending because the installer tried to overwrite it but it was locked (protected). Then Windows rebooted, replaced the file but WFP restored it to its original version.

Does this mean that every time any software is installed in future, the OS will give the message "The System needs to be restarted...." because that pending file will never be cleared??

(and if so, should I try to do anything about it?)

[linder]

"The System needs to be restarted...." is only displayed if your install replaced a locked/in-use file. This creates a new pending action. If the previous pending action was not cleared (e.g. system not rebooted) and the installer was able to replace the file (because something removed the "lock" state) then the install will not request a reboot even when there is still a reboot pending.

Friedrich

[Chris]

In my case the Pending action can never be cleared because it is trying to replace a protected file so will always fail.

So I presume the Pending action will still be there after future restarts?
And therefore future installs will see this Pending action, and suggest restart??

(some installers check for pending items Before starting install, and suggest user restarts first to clear the pending item).

IF the above is all true, then should I try and clear the Registry Pending item?

[linder]

The reboot "should" clear the pending file rename action. Windows deletes the old file, moves the new file from the temporary location to the target location (this removes the registry entry), WFP detects the file change and a rollback to the original file is triggert. So after the reboot, the registry entry "should" be gone. It is not advised to manipulate the pending rename registry on your own. It's very well possible that other programs or a windows update added items.

Friedrich