At 03:08 PM 4/20/98 -0400, you wrote:
>Has anyone seen this symptom?
>
>- User installs ADSM on Windows95
>- User launches ADSM Backup program
>- Win95 system hangs up
>
>How does one go about shooting this kind of problem? Are there trace
>settings that should be used? Any utilities to identify possible DLL
>conflicts?

Paul,

Well, the first mistake (so to speak) is in the part about "User installs..." . In most companies and most environments, allowing users to install software pretty much guarantees user desktop systems that never exactly work right... Installing software under Windows puts files just about anywhere on the system, and if you aren't tracking where those files went and what existing files were replaced/updated, then there's no good way to see what changed.

If you are in an environment where you and the computer support people can control what goes onto user's desktops, then you are halfway there (this requires management support). No software should be installed by the users, and whatever software they want should be approved as necessary for business (not play or experiment or "I just wanted to try it cause it looks cool"). More software equals more risk and greater support costs. You should if possible have a "standard configuration" system set aside that you can use for testing new software installs - this way you don't experiment on user's production systems. Of course, you may know all this already; if so, I apologize for the short lecture :-) .


Now what can you do specifically, and what probably went wrong? When you install any software on Windows95/WinNT, use a tool such as Inctrl3 to track the changes. This is available as freeware from PC Magazine's Web site. The major changes that will torpedo previously-working systems are changes in the shared DLL files in \Windows and/or \Windows\System (System32 for NT4.0 systems). For really tight control of DLLs on systems, a great tool for sniffing out conflicting DLLs is a commercial product called "DLLaGator".

To fix this problem with the situation as it stands, I would:

- Restore the system from a previous backup (at least everything under \Windows)
Get Inctrl3 from www.pcmag.com, install it and read the doc file on how to use it
Make a copy of the \Windows and \Windows\System directories to some temporary directory area
Install ADSM again, using Inctrl3 to track the changes; examine the report file carefully for the changes to existing DLLs (I already know that ADSM *will* make some changes, but the extent of the changes depends on how many of the install options you choose and the current versions of DLLs on the system)
Either carefully copy some or all of the old DLLs over the new DLLs (in which case you risk ADSM not working), or update most or all of the other programs on the system (including Win95 if it needs Svc Pack 1) so that they are more likely to work with the new DLLs

You can also use a program such as FirstAid97 or similar sometimes they work like magic, sometimes you just wasted your money, and occasionally they can screw up the system even worse. Personally, I am very leery of any program that claims to know more than I do and just says "sit back, relax, I'll do everything and you don't need to know how or what I'm doing...". Seldom do they work exactly right, never can they cope with *all* possibilities, and when they don't work right, you have virtually no knowledge of what went wrong.

Hope this helped!

Tony
====================
>Thanks for any suggestions.
>
>..Paul
>
---------------------------------- Tony White, Research Scientist II Tony.White AT gtri.gatech DOT edu Tony White, Research Scientist II Tony.White AT gtri.gatech DOT edu
GTRI Computer Coordinator (404) 894-8157 fax: 894-9337
GT/GTRI/AIST, Atlanta, GA 30332-0816

"Optimist: a Yugo owner with a trailer hitch."