We have a VB5 application that is comprised of an .EXE and numerous
.DLLs. It installs successfully on many Win95 machines by using a DOS
batch file that runs RegSvr32 for each .DLL that needs registering. On
a couple of PCs we have problems where RegSvr32 will 'hang'. On these
PCs, RegSvr32 will always hang during the registering or unregistering
of any .DLLs. We must exit Windows or do Ctrl-Alt-Del and 'End Task' on
each instance of RegSvr32 in order to make them go away. It appears
that RegSvr32 is doing its job even though it locks up, because the app
runs fine after a reboot. This scenario has happened on one PC that was
brand new and one that was well-used (hadn't been rebuilt for numerous
months). We've been unable to find any consistencies or correlation.
What can I look at as a cause for this problem? Are there supporting
programs that RegSvr32 uses that I should do version compares on? Any
ideas will be appreciated. If this is not the correct newsgroup for
this question, please point me to the correct one.
Background:
- Win95 4.00.950 B on all PCs
- RegSvr32: mixture of versions 4.00 and 4.00.1381. 4.00.1381 on
one of the bad PCs, but other PCs with this version work well.
- identical version of our VB app being installed in each case
Thanks,
Rob
rbell1...@netscape.net
Wow. Thats a good one. REGSVR32 does not use anything unusual for support,
just the usual suspects, like KERNEL32, USER32, OLEAUT32 etc... All REGSVR32
does is load the DLL or OCX via LoadLibrary() and then call the internal
registration code inside the component being registered. We have never seen
this one before. Is is possible that multiple copies of REGSVR32 could be
running at the same time? That might make it explode. Can you recreate the
problem? If so, try putting a keypress() inbetween each call to REGSVR32 as
a test to keep them from overlapping and see if it still locks. If its
repeatable, see if you can make REGSVR32 lock with just the single component
outside of your bat file. Also, you could try RegDrop
(http://www.addisonsw.com) and see if it behaves differently, it usually
behaves a bit better than REGSVR32.
Kyle
Rob Bell wrote in message <371C8FED...@netscape.net>...
However, I believe we've tried running the command individually from a command
line and had the same problem. I will have to retest that though.
Thanks,
Rob
I tried just running the RegSvr32 command (as found in our batch file) directly
from the command line. Same results. I get a message box telling me that the
DLL was registered (or unregistered) successfully, but then RegSvr32 stays
hanging around in the task list and locking the DLL.
Also-
I tried RegDrop as you suggested. It responds in the same way as RegSvr32.
After dropping the target DLL onto the RegDrop icon (I placed a shortcut on the
desktop), I get a message saying that it was registered successfully. However,
for each DLL done in this way, I get a copy of RegDrop hanging around in the
task list (with [Not Responding] after it).
Any more suggestions? Does this offer more clues as to where to look next?
Thats a real mess. All that happens REGSVR32 and RegDrop after the component
sucessfully registered message is:
FreeLibrary(theControl);
OleUninitialize();
I would suspect the problem is in the OleUninitialize() call. Its possible
that you might have some OLE components that are not agreeing with each
other. This is a terrbily hard problem to solve - finding which OLE
components de jour work with what...
How old is the version of Windows this happens on? What is the component you
are trying to register - is it your own making or a Windows component?
At one time MS had an update called OADIST.EXE which updated all the OLE
components. A quick search of their site did not find it. There is however a
OLE update at http://www.microsoft.com/windows95/downloads/ Try this at your
own risk, it could add other problems...
Kyle
Rob Bell wrote in message <371F320F...@netscape.net>...