VB6 App Runs For Admin, Not For User
I have a VB6 application that a client is attempting to install and run on a Windows Server 2003 machine. He installs the app as an administrator, and can run it without errors as an administrator, but gets "Error 713: Application-defined or object-defined error in <main form name>, <application name>" when he logs in and tries to run the application as a user.
The fact that the application works fine when he logs in as an administrator makes me believe that all the necessary run-time files, dll's and ocx's are installed. The problem running the application as a user makes me think there is some permission problem causing the error.
I used Inno Setup to build the installer, requiring that an administrator perform the installation so the application would be available to all users. The installation works for both administrator and limited account users on Windows XP.
I have heard there are some problems with Data Execution Prevention (DEP) on some Windows Server 2003 machines, but from what I have seen researching that, those problems are accompanied with errors regarding failed registry writes that aren't occuring with this installation.
I had the client run Regmon while starting the application logged in as both an admin and a user. The Regmon log file for the user account is dramatically shorter (1862 lines vs. 11707) reflecting the interrupted startup, but there aren't any "Access Denied" entries in there, and the final entry is a successful "QueryValue" operation.
Unfortunately, I don't have a Windows Server 2003 machine to test with, and I'm not familiar enough with the OS to help him the way I would like to be able to; I'm concerned that I am missing something simple related to the installation on that platform.
Is there something special that needs to be done to run a VB6 app on Windows Server 2003 as a user?
The fact that the application works fine when he logs in as an administrator makes me believe that all the necessary run-time files, dll's and ocx's are installed. The problem running the application as a user makes me think there is some permission problem causing the error.
I used Inno Setup to build the installer, requiring that an administrator perform the installation so the application would be available to all users. The installation works for both administrator and limited account users on Windows XP.
I have heard there are some problems with Data Execution Prevention (DEP) on some Windows Server 2003 machines, but from what I have seen researching that, those problems are accompanied with errors regarding failed registry writes that aren't occuring with this installation.
I had the client run Regmon while starting the application logged in as both an admin and a user. The Regmon log file for the user account is dramatically shorter (1862 lines vs. 11707) reflecting the interrupted startup, but there aren't any "Access Denied" entries in there, and the final entry is a successful "QueryValue" operation.
Unfortunately, I don't have a Windows Server 2003 machine to test with, and I'm not familiar enough with the OS to help him the way I would like to be able to; I'm concerned that I am missing something simple related to the installation on that platform.
Is there something special that needs to be done to run a VB6 app on Windows Server 2003 as a user?
ASKER
I checked with the client, and no, the server is not a domain controller.
He ran regsvr32 on all the OCX's and DLL's the program uses:
msvbvm60.dll
oleaut32.dll
olepro32.dll
asycfilt.dll
comcat.dll
msmask32.ocx
comdlg32.ocx
mscomct2.ocx
richtx32.ocx
mscomctl.ocx
msdatgrd.ocx
msadodc.ocx
msdatlst.ocx
msinet.ocx
comctl32.ocx
and got one error for asycfilt.dll that was “Asycfilt.dll was loaded, but the DLLRegisterServer entry point was not found. This file cannot be registered.” Other than that, regsvr32 was successful for all the entries.
The program generated the original error when he tried running it afterward.
He ran regsvr32 on all the OCX's and DLL's the program uses:
msvbvm60.dll
oleaut32.dll
olepro32.dll
asycfilt.dll
comcat.dll
msmask32.ocx
comdlg32.ocx
mscomct2.ocx
richtx32.ocx
mscomctl.ocx
msdatgrd.ocx
msadodc.ocx
msdatlst.ocx
msinet.ocx
comctl32.ocx
and got one error for asycfilt.dll that was “Asycfilt.dll was loaded, but the DLLRegisterServer entry point was not found. This file cannot be registered.” Other than that, regsvr32 was successful for all the entries.
The program generated the original error when he tried running it afterward.
I would first try disabling the enhanced IE security (FOR TESTIGN ONLY):
http://www.visualwin.com/IE-enhanced-security/
Next adding the user to the power users local group.
Its most likely permissions/security related, by default win2003 is more restrictive for normal users logging on locally. Are they using this for terminal services? Is there a reason for running windows 2003 and logging on locally? I wouldn't recommend it....
http://www.visualwin.com/IE-enhanced-security/
Next adding the user to the power users local group.
Its most likely permissions/security related, by default win2003 is more restrictive for normal users logging on locally. Are they using this for terminal services? Is there a reason for running windows 2003 and logging on locally? I wouldn't recommend it....
ASKER
I did have the client check permissions on the OCX, DLL, and EXE files. He reported that they were okay, but it seems like that type of conflict had to be the cause. The problem seemed to be stemming from either the Microsoft Data Binding Controls (SP6) or the Microsoft Data Environment (SP6) that were used on the main form, although I built a test app that included the same controls and it ran okay. Very weird.
I finally just spent the weekend re-writing the program. I eliminated all the fancy controls. Now the only reference it has is ADO 2.8 in addition to the VB runtimes, uses only standard components, and uses SQL calls off an ADODB connection object and recorset object for all the data tasks.
It works like that.
What a pain.
I finally just spent the weekend re-writing the program. I eliminated all the fancy controls. Now the only reference it has is ADO 2.8 in addition to the VB runtimes, uses only standard components, and uses SQL calls off an ADODB connection object and recorset object for all the data tasks.
It works like that.
What a pain.
Well I'm glad you were able to finally work around it, please submit this for delete/point refund =).
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
regsvr32 "C:\Program Files\MyProgram\My.dll"