Article ID: 296108
Article Last Modified on 12/26/2006
APPLIES TO
- Microsoft Visual Studio 6.0 Enterprise Edition
This article was previously published under Q296108
SYMPTOMS
You may experience a number of issues in the various Visual Studio programs on a Microsoft Windows NT-based system. These issues are covered in the "More Information" section of this article.
CAUSE
Although some of these issues may occur on Microsoft Windows 95 and Microsoft Windows 98-based systems with specific policies implemented, they usually occur on Windows NT-based systems under either of the following circumstances:
- When you attempt to install Visual Studio 6.0 with less than Administrator rights on the local computer.
- When you use one of the programs (such as Visual Basic 6.0) and create DLLs or OCXs (OLE custom controls) with less than full control of the required registry keys.
These issues occur because of insufficient Windows NT permissions.
MORE INFORMATION
Visual Studio Program Installation
When you install Visual Studio programs on a computer that does not have sufficient permissions to access the required registry keys, you may receive one of the following error messages:
-or-
-or-
These error messages can occur because of insufficient permissions to complete the installation or requested process. To resolve this issue, follow these steps:
- Start Regedt32.
- Browse to each of the following registry keys:
HKEY_CLASSES_ROOT\TypeLib\{000204EF-0000-0000-C000-000000000046}\6.0\9\win32
HKEY_CLASSES_ROOT\TypeLib\{AC0714F2-3D04-11D1-AE7D-00A0C90F26F4}\1.0\0\win32
HKEY_CLASSES_ROOT\TypeLib
HKEY_CLASSES_ROOT\Interface
HKEY_CLASSES_ROOT
- Select each key. On the Security menu, click Permissions.
- Make sure that the local computer's Administrators group has full control. Then, click to select the Allow inheritable permissions from parent to propagate to this object check box, or on a Windows NT-based system, click to select the Replace permission on existing subkeys check box.
- Click Apply.
- Click Run.
Visual Basic Program Use
When Visual Basic 6.0 is installed by an administrator on either a Windows NT 4.0 or Microsoft Windows 2000-based system, generic users can run the Visual Basic application. However, if they try to add components from the Project menu, they receive the following error message:
When you access the References dialog box in the Visual Basic integrated development environment (IDE) or any Visual Basic for Applications-enabled application, you receive the following error message:
To grant user access, create a new users group such as VB Programmers, using the User Manager for Domains or Computer Management interface. Then, follow these steps:
- Click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
- To expand the branches, click the plus sign (+) next to System Tools on the Tree tab, and then click the plus sign next to Local Users and Groups.
- Right-click the Groups folder to view the shortcut menu. Click the New Group menu to view the New Group dialog box.
- Give the new group a group name, such as VB Programmers, and a description, and then add one or more members. Click Create to save the new group.
NOTE: In Windows NT 4.0, use User Manager for Domains.
After you finish the preceding steps, modify the registry. Modify the permissions on the following keys, and then add VB Programmers to these keys with full control, inheriting the permissions down the key. To do this, follow these steps:
- Start Registry Editor (Regedt32.exe).
- Locate the following keys in the registry:
HKEY_CLASSES_ROOT\TypeLib
HKEY_CLASSES_ROOT\Interface
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Interface
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\TypeLib
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual Basic
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio
Existing users may require permissions to the following key as well:
HKEY_CURRENT_USER\Software\Microsoft\Visual Basic
- For each key, click Permissions on the Security menu. Add the VB Programmers group to the key, and then click Apply.
- Select the new VB Programmers group, click to select the Allow Full Control check box, and then click to select the Allow inheritable permissions from parent to propagate to this object check box.
NOTE: On Windows NT 4.0-based systems, click to select the Replace permission on existing subkeys check box. - Click Apply, and then click OK.
- Quit Registry Editor.
Note that when you access from REGEDT32.exe, some registry keys are dimmed and inaccessible. For example:
HKEY_CLASS_ROOT\TypeLib\{...}
Other issues that you may encounter with these registry keys include the following:
- You cannot delete these keys, not even from the local Administrator account.
- You cannot assign or view permissions.
- You cannot take ownership of the keys.
This behavior is caused by insufficient permissions to the registry.
HKEY_CLASSES_ROOT is dynamic and is built on startup. The HKEY_LOCAL_MACHINE\Software\Classes key is read into memory and is accessible as HKEY_CLASSES_ROOT. If you add a key to HKEY_LOCAL_MACHINE\Software\Classes, it is immediately replicated to HKEY_CLASSES_ROOT.
*** Additional Steps to Correct These Issues***
First you need to figure out which registry key or keys are affected. This can be done in two ways:
- Use REGEDT32.exe to scan for keys that are dimmed in HKEY_CLASSES_ROOT\TypeLib and HKEY_CLASSES_ROOT\CLSID.
-or- - Use the RegMon utility to monitor registry activity.
For more information about RegMon, or to download RegMon, browse to the following Sysinternals Web site: Run the filtering processes for Visual Basic, and then try accessing the References dialog box in Visual Basic. When you receive the error message, switch to RegMon, and then make note of the last keys that were successfully read or written. (These should be from HKEY_CLASSES_ROOT\TypeLib or HKEY_CLASSES_ROOT\CLSID.)
To resolve the permissions issue, follow these steps:
- Load REGEDT32, and then locate the keys from the first bullet in the "Additional Steps to Correct These Issues" section that are dimmed, or the keys that you noted from the subsequent bullet.
NOTE: If you used the method described in the second bullet in the "Additional Steps to Correct These Issues" section, look at the key or subkey that immediately follows it in the Registry after you locate the key. If you did not have the appropriate permissions to access the key, it would not have even been logged through the RegMon utility and, therefore, the entry that you noted in the second bullet will be the last successful read/write operation. Therefore, the operation that followed that successful operation is responsible for the error message. - On the Security menu, provide the appropriate permissions to the key so that you (and Visual Basic) can access it:
- Administrators - Full ControlEveryone - ReadSystem - FullUsers - ReadModify the user list to suite your needs
- Sometimes REGEDT32 is not able to access the key, and therefore you receive an error message stating that the security account information cannot be retrieved or found. To resolve this issue, follow these steps:
- Under Control Panel, double-click Services.
- Verify that the Task Scheduler is running, and then start it if it is not.
- Open a command prompt (MS-DOS prompt).
NOTE: The window caption displays Command Prompt. - Type the following command to schedule a new command prompt:
AT 13:10 /Interactive cmd.exe
- Change 13:10 to whatever time you want the cmd.exe (command prompt) to run. For example, change it to one or two minutes from your current time.
- Wait until this new command prompt starts.
NOTE: The window caption is similar to the following:C:\Winnt\System32\MSTask.exe
If the command prompt fails to start, please see the following Microsoft Knowledge Base article:
Because the Task Scheduler is running under the SYSTEM account, the new command prompt runs under the SYSTEM security context.193852 Task Scheduler May Fail to Run Job When Scheduled
- From the new command prompt, type the following, and then press ENTER:
Because you start this process from the SYSTEM command prompt, REGEDT32 also runs under the SYSTEM security context.
REGEDT32.EXE
- Repeat step 2, and then reset the permissions.
Use of Other Visual Studio Programs
Steps for other Visual Studio programs are essentially the same as those outlined in the "Visual Basic Program Use" section of this article, with the addition of the requirement of permissions for the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\DevStudio
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTML Help Collections
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual Component Manager
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual Modeler
Existing users may require permissions to the following keys as well:
HKEY_CURRENT_USER\Software\Microsoft\DevStudio
HKEY_CURRENT_USER\Software\Microsoft\Visual Basic
HKEY_CURRENT_USER\Software\Microsoft\Visual Modeler
HKEY_CURRENT_USER\Software\Microsoft\VisualFoxPro
Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.
The third-party products that are discussed in this article are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.
REFERENCES
For additional information about registry permissions, click the article numbers below to view the articles in the Microsoft Knowledge Base:
268553 PRB: Visual Studio, Office Developer Installation Problems Occur If Crystal Reports 8 Is Installed
269383 PRB: 'Error Accessing the System Registry' Message When Displaying VB/VBA References
259569 PRB: Installing Third-Party Product Breaks Windows 2000 MDAC Registry Settings
193852 Task Scheduler May Fail to Run Job When Scheduled
Additional query words: Admin Rights Permissions configuration
Keywords: kberrmsg kbprb KB296108
