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?
LVL 2
jay_s5Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MazaraatCommented:
Is the server a domain controller?  Most likely the cause is the dll's and/or OCX's aren't registered properly for the user (different permissions) to use them.  try re-registering them from the command shell.  

regsvr32 "C:\Program Files\MyProgram\My.dll"
jay_s5Author Commented:
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.

MazaraatCommented:
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....

Active Protection takes the fight to cryptojacking

While there were several headline-grabbing ransomware attacks during in 2017, another big threat started appearing at the same time that didn’t get the same coverage – illicit cryptomining.

jay_s5Author Commented:
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.
MazaraatCommented:
Well I'm glad you were able to finally work around it, please submit this for delete/point refund =).
GranModCommented:
Closed, 500 points refunded.
GranMod
The Experts Exchange
Community Support Moderator of all Ages

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.