Custom Application Problems

I write custom Microsoft Access applications, and most of them have worked fine on Windows NT and Citrix WinFrame clients. Recently, I installed an application on a Citrix MetaFrame server, and it seemed to work fine until I logged on as a regular user instead of an administrator. What went wrong?

It sounds like your program is having a problem getting to the files it needs to run—most likely .dll or .ini files. Either you failed to install the application for multiple users, or you need to tune the application for multiuser use.

When you install an application on a Windows NT Server 4.0, Terminal Server Edition (TSE) server, Microsoft and Citrix recommend that you first run Change User /Install to set the application for multiple users. Change User /Install, which you can run from a command line or from the Control Panel’s Add-Remove Programs applet, creates .ini files for your custom application in the TSE system directory. The system uses these files as masters to create user-specific .ini files. All Registry entries that the program creates will shadow in the HKEY_LOCAL_MACHINESOFTWARE MicrosoftWindows NTCurrentVersionTerminal ServerInstall Registry key.

The first time a user runs the application, it looks in the user home directory for the .ini files. If it doesn’t find the files there, the application copies them from the system directory, which ensures that each user has a unique copy of the .ini files. Any new .ini files that the system creates during runtime appear in the home directory. Any keys that the system adds to HKEY_CURRENT_USER copy under the Software key, and any keys the system adds to HKEY_LOCAL_MACHINE copy under the Machine key. If you didn’t install the application with the Change User /Install procedure, you should uninstall and reinstall the application.

If that doesn't resolve the situation, then you probably have a problem .dll or .ini file. When developing an Access application, you should try to follow the standard methods that the Microsoft API provides for writing .ini files and pointing to .dll files. For example, if you are using an .ini file that would typically reside in the C:WindowsSystem directory, you should locate that directory with the API command Getwinsysdir. Doing so will help the Change User /Install command to store a central file in the system and to copy it to each user for his or her own use. If you don’t mark .dll files as sharable, or if you fail to configure some files with the correct permissions, then it’s up to the installer to try to remedy the situation. For an example of a .dll permissions problem, see the Citrix Solution Knowledgebase.

Finding the problem file can be time consuming and frustrating. Fortunately, there are tools you can use. The ones I use most often are System Internals’ Filemon and Regmon, which you can download from the company's Web site. Filemon is a GUI-device driver combination that monitors and displays all file-system activity. It explores the way Windows works by watching how applications use files and DLLs, then tracks down problems in system or application configurations. If a file is missing or you have a permission problem, Filemon will probably find it.

Regmon is a Registry-spy utility that watches and displays systemwide Registry access as it occurs. With Regmon, you can track down problems that result from misconfigured Registry settings.

Once you have retrieved these tools, you can use them while running your new application to find offending files. The tools will tell you which files the application accesses and with which permissions, and it will report any errors that occur while the application runs. You can correct most of these errors by copying an .ini file, changing permissions on a file, moving a file to a specific directory, or registering a .dll properly.