| Author |
dll hell: how to troubleshoot self-registration failure
|
|
| River Ross 2005-04-28, 9:02 pm |
| I have a classic example of self-registering dlls for a 3rd party control
(Crystal Reports 9 btw) that seem to install properly on every other machine
out there but one XP SP1 machine. Of course this is an end users machine
and there's only so much I can put them through over the phone to try to
troubleshoot this. I think I read and followed the CR9 documentation fairly
well etc. so I think I included all the files and supporting files the
control claims to need and the fact that every other machine it works with
fine. The only other theory I have is that something is missing or corrupt.
For example could a rogue application manage to replace atl.dll with a 9x\Me
version or something like that?
Is there any easy way to debug this in a way that an end user is capable of
tolerating (for example one thing I read said open regsrv32.exe in
depends.exe and profile it registering the dll... I am not gonna try to walk
an end user through that LOL).
The dlls that won't register are:
crviewer9.dll
crtslv.dll
| |
| CheckAbdoul 2005-04-28, 9:02 pm |
| "River Ross" <river.ross@sbcglobal.net> wrote in message
news:UVace.1861$gd5.810@newssvr12.news.prodigy.com...
> I have a classic example of self-registering dlls for a 3rd party control
> (Crystal Reports 9 btw) that seem to install properly on every other
machine
> out there but one XP SP1 machine. Of course this is an end users machine
> and there's only so much I can put them through over the phone to try to
> troubleshoot this. I think I read and followed the CR9 documentation
fairly
> well etc. so I think I included all the files and supporting files the
> control claims to need and the fact that every other machine it works with
> fine. The only other theory I have is that something is missing or
corrupt.
> For example could a rogue application manage to replace atl.dll with a
9x\Me
> version or something like that?
>
> Is there any easy way to debug this in a way that an end user is capable
of
> tolerating (for example one thing I read said open regsrv32.exe in
> depends.exe and profile it registering the dll... I am not gonna try to
walk
> an end user through that LOL).
>
> The dlls that won't register are:
> crviewer9.dll
> crtslv.dll
>
>
One way is to ask the customer to run the filemon utility and save the
results. You can analyze the results to see if there are any issues on
finding dependent DLL files.
--
Cheers
Check Abdoul [VC++ MVP]
-----------------------------------
| |
| Brian Bischof 2005-04-28, 9:02 pm |
| I have a versioning tool that looks at all the CR dlls on your computer and
exports it to an XML file. You can have them run the program and email it to
you. Then you can compare your file with theirs and see if anything jumps
out at you. There is a link on my website.
www.CrystalReportsBook.com
HTH,
Brian Bischof
"River Ross" <river.ross@sbcglobal.net> wrote in message
news:UVace.1861$gd5.810@newssvr12.news.prodigy.com...
> I have a classic example of self-registering dlls for a 3rd party control
> (Crystal Reports 9 btw) that seem to install properly on every other
machine
> out there but one XP SP1 machine. Of course this is an end users machine
> and there's only so much I can put them through over the phone to try to
> troubleshoot this. I think I read and followed the CR9 documentation
fairly
> well etc. so I think I included all the files and supporting files the
> control claims to need and the fact that every other machine it works with
> fine. The only other theory I have is that something is missing or
corrupt.
> For example could a rogue application manage to replace atl.dll with a
9x\Me
> version or something like that?
>
> Is there any easy way to debug this in a way that an end user is capable
of
> tolerating (for example one thing I read said open regsrv32.exe in
> depends.exe and profile it registering the dll... I am not gonna try to
walk
> an end user through that LOL).
>
> The dlls that won't register are:
> crviewer9.dll
> crtslv.dll
>
>
| |
| River Ross 2005-04-29, 4:03 am |
| Thank you both I will give these a shot.
"River Ross" <river.ross@sbcglobal.net> wrote in message
news:UVace.1861$gd5.810@newssvr12.news.prodigy.com...
>I have a classic example of self-registering dlls for a 3rd party control
>(Crystal Reports 9 btw) that seem to install properly on every other
>machine out there but one XP SP1 machine. Of course this is an end users
>machine and there's only so much I can put them through over the phone to
>try to troubleshoot this. I think I read and followed the CR9
>documentation fairly well etc. so I think I included all the files and
>supporting files the control claims to need and the fact that every other
>machine it works with fine. The only other theory I have is that something
>is missing or corrupt. For example could a rogue application manage to
>replace atl.dll with a 9x\Me version or something like that?
>
> Is there any easy way to debug this in a way that an end user is capable
> of tolerating (for example one thing I read said open regsrv32.exe in
> depends.exe and profile it registering the dll... I am not gonna try to
> walk an end user through that LOL).
>
> The dlls that won't register are:
> crviewer9.dll
> crtslv.dll
>
| |
| John Mishefske 2005-04-29, 4:03 am |
| River Ross wrote:
> Thank you both I will give these a shot.
>
> "River Ross" <river.ross@sbcglobal.net> wrote in message
> news:UVace.1861$gd5.810@newssvr12.news.prodigy.com...
>
>
>
>
Another product that is useful in identifying dependencies is the
Dependency Walker at http://www.dependencywalker.com/
--
'---------------
'John Mishefske
'---------------
|
|
|
|