Package Installation Fails (msvcrt.dll, expsrv.dll) 2

[Jefftopia]

I am using VB 6.0 SP5. I recently upgraded to SP5. Since then I have had the following problem...

When I try to install a package to a client machine, the installation fails when it is installing the following two files:

msvcrt.dll
expsrv.dll

The installation prompts for a reboot. However, after rebooting, the installation still prompts for a reboot. This process continues indefinitely. Installation is not allowed to continue.

I have tried excluding these files from the package. This allowed the package to be installed. However, I had problems with the installed program. For example, I received the following error:

Error 3663
Could not load MSJET35.DLL

I had heard there was a problem with expsrv.dll in that it was mistakenly marked as self registering for version less than SP3. I have SP5. This problem was apparently resolved in SP3.

Does anyone have a clue as to what is happening here? It is clear that I need these files since my program will not funciton properly without them. Please help.

Thanks

 

[Jefftopia]

I have been able to isolate the problem to the msvcrt.dll file. If I exclude this file I cannot load msjet35.dll. Consequently, I must include this file. However, my installation fails if I include it. What is this file used for? How can I resolve the issue? Please help

 

[zemp]

You have come accross one of the limitations of the PDW. Basically it is trying to replace msvcrt.dll on the target machine because your package uses a newer version. However msvcrt.dll is in use by windows and the PDW cannot replace a file in use. That is why it reboots, hoping that the file will no longer be in use when it continues. But of course it is in use it is used by windows so you just ends up in a vicious circle.

There area couple of things that you can do.
1. Don't include that file. All windows operating systems have it. But I don't recommend this because your app may need the newer version of the file to operate properly.
2. Change to another installation package. You can download visual studio installer from microsoft for free. Myself, I switched to INNO setup, also a free download from

http://www.jrsoftware.org.

3. There is a way to manipulate the setup.lst file created by the PDW. I have never done it but I have seen that solution posted on this forum. Unfortunatly tek-tips search is down for maintanence right now.

This problem can also happen for other files and not just mcvrt.dll. Thanks and Good Luck!

zemp

 

[MarkSweetland]

If you are trying to install to Win 2000 or up, it sounds as if you are fighting the Windows File Protection "feature".

check out thread222-258464

Mark

 

[zemp]

That cetainly makes sense and explains it better than I did, but I had a situation where I did make sure that all the latest was added on the machines but still the problem occured. Both my development and the target were win 2000.

Thanks and Good Luck!

zemp

 

[ZOR]

Is it a question of getting a newer version of the file to cure it?. I have the same problem in trying to put an application on a an NT 4.00 machine, I thought it was because the file was already in use that caused the problems. I found a bit of software which displayed all the files that were in use on the target machine, and svcrt.dll was in use. I was then told the only way I could put the application on the machine was by an installer that forced the target machine to reboot, and while rebooting, put the files on. Am I wrong. Sorry to invade the thread, but having the same problem, going down similar roads, it would be good to solve it. I downloaded Inno, but cannot understand how to use it at present. Thanks, regards

 

[zemp]

INNO can be a bit tricky at first. The web site has lots of examples and a newsgroup that you can search for other examples. I too did some guessing when I was creating my first installation package with INNO but after a couple of times it ends up being faster than the PDW. Thanks and Good Luck!

zemp

 

[ZOR]

Thanks Zemp. Its a shame there is not any link software between Inno and the PDW, that would enable the main installation to be carried out by PDW, and then the problamatic bits be shoveled in by Inno. Can Inno force a reboot/install on an NT machine. I have looked throgh the documentation but cannot find any mention?. Thanks. Appologies Jefftopia for the intrusion, but hopefully with more inputs might get an answer. Regards

 

[zemp]

With INNO I have had no problems on any machines with the problem files that have been mentioned in this thread, and no reboots.

You will however find that some of the things that the PDW does automatically will cause a few minor problems until you sort them out. One issue that I have to keep track of is whether a file needs to be registered or not. The PDW took care of this, with INNO you have to specify whether or not to register the file. Therefore you have to know if the file needs to be registered with windows.

I found the following link very helpful in finding out about microsoft dlls.

http://support.microsoft.com/default.aspx?scid=/servicedesks/fileversion/dllinfo.asp&SD=MSDN&FR=0

Thanks and Good Luck!

zemp

 

[CCLINT]

>one of the limitations of the PDW

You can overcome this problem in the P&D by forcing the replacment of the file in question. [/b][/i][/u]_{*******************************************************
General remarks:
If this post contains any suggestions for the use or distribution of code, components or files of any sort, it is still your responsibility to assure that you have the proper license and distribution rights to do so!}

 

[lalee5]

After reading this thread I am still really confusing as to what I should do to resolve my problem.

What does the following by CCLINT means:?

>one of the limitations of the PDW

You can overcome this problem in the P&D by forcing the replacment of the file in question.


How do you force the file?

More exmples please

 

[tbuch]

Make sure the latest Service Packs for Win2K are installed on target machine.

tbuch

 

[comaboy]

Just my 2p...

I had this problem with a diverse installation ranging from 98 through NT, 2000 and XP. Installed fine. On some of the machines, but ended up in true DLL-Hell on others . The way around it? Edit your setup.lst to install the files in the Program Directory, NOT in the windows system. That way, there are no DLL's to overwrite.

Now I just KNOW I'm asking for some real verbal abuse for suggesting such a profane hack, but when you're up against a clock you gotta with what works!

The other way to get around it is boot the machine into a command prompt, manually overwrite the DLL's, and re-register when you boot Windows. Again, it's a hack (and possibly very dangerous). Don't forget to TAKE BACKUPS!