Gary2397
asked on
Application attempts to install Access 2000 Runtime
I have a vb6 application that is distributed to a client machine. The client machine is windows XP with Access 2003 installed. The application runs fine, except when some of the forms load and load data from an Access database, the application attempts to install Access 2000 Runtime. I can cancel the install window and the appliction continues to run fine. What would cause this problem to occur? Would it have to do with dependencies or references in the deployment package, setting up the DSN, etc?
ASKER
Could you explain this a little more, I am a little unclear:
At the same time as the self-repair kicking off an event should be written into the Application event log saying exactly why the MSI is self-repairing. The event ID is usually '1001' and the description will probably be along the lines of:
"Detection of product 'chalice', feature 'FeatureName' failed during request for component '{D2D7B4BF-6DDA-11D5-8B3F-
At the same time as the self-repair kicking off an event should be written into the Application event log saying exactly why the MSI is self-repairing. The event ID is usually '1001' and the description will probably be along the lines of:
"Detection of product 'chalice', feature 'FeatureName' failed during request for component '{D2D7B4BF-6DDA-11D5-8B3F-
Gary2397,
No problem; Immediately after the issue occurs, open up the Event Viewer on the machine (Start/Run.. and 'eventvwr') and look in the 'Application' Log and one of the most recent entries should relate to the self-repair of the Access 2000 RT and also give some idea as to why it felt it needed to self repair (BTW, ignore the reference to 'chalice' in the original post, it'll actually refer to the Access RunTime!)
If you find the appropriate entry, but still can't fathom what it means, please paste the Event description here.
cheers,
No problem; Immediately after the issue occurs, open up the Event Viewer on the machine (Start/Run.. and 'eventvwr') and look in the 'Application' Log and one of the most recent entries should relate to the self-repair of the Access 2000 RT and also give some idea as to why it felt it needed to self repair (BTW, ignore the reference to 'chalice' in the original post, it'll actually refer to the Access RunTime!)
If you find the appropriate entry, but still can't fathom what it means, please paste the Event description here.
cheers,
ASKER
I did just as you said, and this is what came up with:
Detection of product '{00180408-78E1-11D2-B60F-
Now, I have to research this.
Detection of product '{00180408-78E1-11D2-B60F-
Now, I have to research this.
Ok .. I beleive that particular component is 'Global_Vba_VBStandardForm
In theory, if you take a note of the size, date/time stamp and also the version of this file (by right mouse clicking it,selecting 'properties' and then the 'version' tab) you should see it get replaced by a different version when the Access RT fixes itself.
However, it's worthwhile investigating what other application may be replacing the file so that the Access RT feels it needs to 'fix' it - in other words identify the actual root cause of the issue.
It shouldn't be another MSI as they *should* be authored to correctly handle versioning mismatches, so it's likely to be a legacy application install overwriting 'msstdfmt.dll' when it shouldn't be - does the vb6 application distribution you're installing contain 'msstdfmt.dll' ?
cheers,
In theory, if you take a note of the size, date/time stamp and also the version of this file (by right mouse clicking it,selecting 'properties' and then the 'version' tab) you should see it get replaced by a different version when the Access RT fixes itself.
However, it's worthwhile investigating what other application may be replacing the file so that the Access RT feels it needs to 'fix' it - in other words identify the actual root cause of the issue.
It shouldn't be another MSI as they *should* be authored to correctly handle versioning mismatches, so it's likely to be a legacy application install overwriting 'msstdfmt.dll' when it shouldn't be - does the vb6 application distribution you're installing contain 'msstdfmt.dll' ?
cheers,
ASKER
Yes, the distribution package does include the msstdfmt.dll.
ASKER
I should have listed this earlier, but just saw it in the event log.
This is the error thrown before the above mentioned error:
Detection of product '{00180408-78E1-11D2-B60F-
This is the error thrown before the above mentioned error:
Detection of product '{00180408-78E1-11D2-B60F-
You've not said, but I presume that this only occurs when the vb6 application is *first* ran (however, if you cancel the 'fix' dialog, it occurs each time it runs?)
If that's the case, then it's very likely that your VB6 distribution is overwriting an *existing* version of msstdfmt.dll when it shouldn't be doing (hence the Access RT MSI 'fixing' it when the 'damaged' comes to be used)
The only real solution is to correct your VB6 application distribution so that it doesn't push out the file at all (it's bad practice to deploy system DLLs via an application deployment anyway) or only push it out if it doesn't already exist or is a lesser version (though I think the VB6 PDW should do that anyway...?)
However, before doing this, you'll need to understand what's already installed on the target computers - I'm not sure whether msstdfmt.dll is a DLL installed as part of the base O/S or whether it's installed as part of MS Office for instance. If it's already on one of your clean freshly installed machines (if you have a 'standard' image) then you shouldn't have any issues removing it from your VB6 distribution..
Good luck..
If that's the case, then it's very likely that your VB6 distribution is overwriting an *existing* version of msstdfmt.dll when it shouldn't be doing (hence the Access RT MSI 'fixing' it when the 'damaged' comes to be used)
The only real solution is to correct your VB6 application distribution so that it doesn't push out the file at all (it's bad practice to deploy system DLLs via an application deployment anyway) or only push it out if it doesn't already exist or is a lesser version (though I think the VB6 PDW should do that anyway...?)
However, before doing this, you'll need to understand what's already installed on the target computers - I'm not sure whether msstdfmt.dll is a DLL installed as part of the base O/S or whether it's installed as part of MS Office for instance. If it's already on one of your clean freshly installed machines (if you have a 'standard' image) then you shouldn't have any issues removing it from your VB6 distribution..
Good luck..
ASKER
Yes, when i cancel the Windows Installer dialog, the problems persists each time the application is executed. I presume you are using the 'fix' dialog to refer to the 'windos installer' dialog that attempts to install Access 2000. I checked the version of the msstdfmt.dll on my machine and it is 6.1.97.82, this is the same version being installed the the instller package. I re-created the installer package and excluded the msstdfmt.dll file and the same error persisted.
Ah ha.. only just seen your comment at 10:03 regarding 'HKEY_CURRENT_USER\Softwar
If not, then it may just be that everything is actually 'working as designed' - it's just that the Access RT component that's being referenced by your application *needs* to create some specific data for *each user* of the application (which is why it attempts to write to HKEY_CURRENT_USER rather than HKEY_LOCAL_MACHINE)
If this is indeed the case, then I'd suggest just leaving it as is as it's likely that the data it writes to the registry key is perculiar to the currently logged-in user and - as long as you don't cancel the dialog - it should only need to 'repair' once for each user of the application on a given machine.
(However, my earlier comment about removing the system DLLs from your VB6 distribution is still valid!)
cheers,
If not, then it may just be that everything is actually 'working as designed' - it's just that the Access RT component that's being referenced by your application *needs* to create some specific data for *each user* of the application (which is why it attempts to write to HKEY_CURRENT_USER rather than HKEY_LOCAL_MACHINE)
If this is indeed the case, then I'd suggest just leaving it as is as it's likely that the data it writes to the registry key is perculiar to the currently logged-in user and - as long as you don't cancel the dialog - it should only need to 'repair' once for each user of the application on a given machine.
(However, my earlier comment about removing the system DLLs from your VB6 distribution is still valid!)
cheers,
ASKER
I have fixed the error. Let me tell you how I did it. I want to give you the points, becuase you led me in the right direction.
First of all, to address the above post: When I let the installer run through (install Access 2000 Runtime), I later develop an error in the application that will not allow me to view an Access report that I call and open from the application.
Now, for the fix: In the above error: Detection of product '{00180408-78E1-11D2-B60F-
I went to Start - Run - "regedit" . And manually created:
[HKEY_CURRENT_USER\Softwar
"UserData"=dword:00000001
And
[HKEY_CURRENT_USER\Softwar
"UserData"=dword:00000001
"OSAShortcut"=dword:000000
And I executed the application, without the Installer window appearing and I can open and view the Access Reports.
Could you tell me why I had to do this, or why this worked, and I will be glad to give you the points.
First of all, to address the above post: When I let the installer run through (install Access 2000 Runtime), I later develop an error in the application that will not allow me to view an Access report that I call and open from the application.
Now, for the fix: In the above error: Detection of product '{00180408-78E1-11D2-B60F-
I went to Start - Run - "regedit" . And manually created:
[HKEY_CURRENT_USER\Softwar
"UserData"=dword:00000001
And
[HKEY_CURRENT_USER\Softwar
"UserData"=dword:00000001
"OSAShortcut"=dword:000000
And I executed the application, without the Installer window appearing and I can open and view the Access Reports.
Could you tell me why I had to do this, or why this worked, and I will be glad to give you the points.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
An MSI based application (such as the Access 2000 RT) will behave like this if they detect that one of their 'components' isn't as expected (which usually means missing but could also mean that the version has been downgraded by another non-MSI based install for instance)
At the same time as the self-repair kicking off an event should be written into the Application event log saying exactly why the MSI is self-repairing. The event ID is usually '1001' and the description will probably be along the lines of:
"Detection of product 'chalice', feature 'FeatureName' failed during request for component '{D2D7B4BF-6DDA-11D5-8B3F-
The component ID referenced is the actual item that's 'missing' (or damaged or the incorrect version) on the machine - the ID directly refers to one of the components in the applications MSI and establishing which particular component it is will allow you to identify the other potentially rogue app that's also distributing it incorrectly etc.
cheers,