Wrong DLL Being Called

[ksangree]

I am dealing with a massive legacy program written in VB6. On start up, the program displays a splash screen and then calls a few COM DLLs to do some housekeeping like retrieving the user's registration info, default data paths, retrieving report headings, etc. On very rare occasions, if the user has (or had) Autocad installed, one of the calls to one of the COM DLLs results in the firing up of the Autocad installation server.

The user's computer will sit there until a disk with Autocad.msi is inserted or the user cancels.

What gives? I have no idea where to even begin to track this problem down. HELP!

Thanks,
Karl

[HanneSThEGreaT]

Do you know how these dlls scans for AutoCAD, the problem most probably lies in there, causing this ¿

[ksangree]

Nothing scans for Autocad. All the com objects referenced are from my program and not Autocad. There are no external calls made other than to the com objects intrinsic to the program and Windows APIs. The program functions perfectly if Autocad is not installed. After installing Autocad, the user runs my program and instead of opening the main form, something is triggering the Autocad install program.

I am clueless...

[Hack]

Does the program do any registry reading?

[HanneSThEGreaT]

What I was meaning with scans, ksangree, was that one of the dlls scans for AutoCAD, through the registry, full stop ( as Hack also noticed ). So again, do you have access to these dlls, and if so, can you enlighten us with their codes or something. The problem ( I repeat ) lies in one of those DLLs, and it is looking at the wrong place for AutoCAD.

[ksangree]

Gentlemen,

Thanks for all your help so far. Needless to say, I am as frustrated as a one armed paper hanger.

There are a couple calls to the registry.
All are formatted similar to the code below:

   Me.lblName = GetSetting("TRAXPro", "Registration", "Name")
   Me.lblCompany = GetSetting("TRAXPro", "Registration", "Company")
   Me.lblSerial = GetSetting("TRAXPro", "Registration", "Serial")

Thanks again,
Karl

[Hack]

Do a registry wide search for "AutoCad" and see what that brings up.

[ksangree]

Way ahead of you.
There is a plethora of AutoCad and AutoDesk entries.

[westconn1]

what are the names of the dlls that cause the problem?
is acad overwriting one because of a duplicate name? check file datetimes
or is acad by some chance using the same clsid, i know this is not supposed to happen

[ksangree]

Pete,

I was thinking it may be a duplicate CLSID as bizarrely remote as that seems. All my DLLs are named with convention TProXXXX.dll, where XXXX is a 4 character identifier. For example the dll that produces volume reports (it's a traffic counting program) is TProVolR.dll. I don't think any of the ACAD dlls begin with TPro, but I'll double check.

Is there anywhere where I can find a good tutorial on how to quickly find a duplicate CLSID? I have asked the client to export the HKEY_CLASSES_ROOT branch of his registry, so I can write a quick utility to scan that if I new what I was looking for.

I am way more knowledgeable about VB programming than I am the inner working of the registry.

Thanks again for all the help,
Karl

[HanneSThEGreaT]

The way I have always checked for the existence of certain applications was to scan this key in the registry :
HKEY_CLASSES_ROOT
Then, based on the particular app I'm looking for ( say for example I'm looking for PowerPoint ), I'll do this :
PowerPoint.Slide\CurVer

Now, if HKEY_CLASSES_ROOT\PowerPoint.Slide\CurVer is not empty, I know it exists.
You could do the same for AutoCAD.

Another way is to check to see if AutoCAD's extension ( what it use to save the files as ) is also there, also in the HKEY_CLASSES_ROOT

[ksangree]

Thanks one and all for your help. I am currently coding a little utility to scan thru the customer's HKEY_CLASSES_ROOT branch of the registry.