Not to bore you, I'm gonna make long story short. Two machines, identical systems on them, identical programs (mostly). One has Visual Studio installed, one has ... uhmm, something else.
Sometimes when I try to install applications from let's say a CD, Visual Studio's Just-In-Time Debugger pops up, reports an "unhandled win32 exception in ..." and asks whether I want to debug using "New instance of Microsoft VIsual Studio 2010". If I choose Yes, it runs VS, if I choose No it closes the thing, and I'm back in Windows Explorer.
Which would be ok, except I know the application is perfectly all right, and this way I cannot install it (in this latest cast it was the client from my bank for internet banking and paying bills and such).
So, how do I get rid of that thing (just-in-time debugger)?
I don't want to uninstall VS since I'm using it daily, of course.
Edit 1 :: I tried disabling Just-In-Time debugging in VS's Tools/Options/Debugging/Just-In-Time, then unchecking all three checkmarks, but that just gave another error when trying to run the executable installation program.
An unhandled win32 exception occurred in autorun.exe [some number]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time debugging can be enabled from ...
Check the documentation index for 'Just-in-time debugging, errors' for more information.
Very informative :/
Edit 2 :: The application runs fine on the other machine that doesn't have VS installed. To a large extent software on both machines is the same, with just some minor differences (systems installed from image). Minor differences: notepad2, ++, git, ... some small stuff that is left to dev's own choosing.
I don't want this to sound as rant against VS, since I realize it's taking that tone, but I extremelly dislike software that is not self contained and messes other software up. And I had the same problem before with other applications as well. So for now, I'm blaming VS.
If necessary, I'm willing to disable all kinds of debugging for this thing to work permanently (mostly use print statements anyways), if that will help. And if it possible.
I just had this problem today with Visual Studio 2013. This MSDN article:
Just-In-Time Debugging in Visual Studio works for me. In my case, I just rename Debugger to Debugger_del and DbgManagedDebugger to DbgManagedDebugger_del.
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, also delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
I am adding this response even though this is an old topic because I have just spent most of the day on this very issue and finally solved it. Every solution I found focused on disabling or turning off JIT debugging in Visual Studio, deleting keys from the registry or changing IE script debugging settings. But if you don't have a registered copy of VS, you have a problem. Of course, many of the solutions work in different ways but then you are left with the error above "no installed debugger has just-in-time debugging enabled" which no-one seems to have an answer for. However, the answer is not to disable JIT but rather stop server side debugging in your application. Unless you actually want to do server side debugging it is not necessary for it to be on.
It makes complete sense to me now because I had server side debugging turned on in ASP. Before installing VS, it made no difference because no debugger was assigned to handle the bugs so they were sent to the browser. Once I installed VS, JIT took over and did what tit was supposed to do.
So the quick answer, open IIS, click on default sites or your sites and in your application settings, ASP in my case, turn off server side debugging!!
It may not be everyone's answer, or even the solution to the above problem, but hope it provides more insight to this problem and help someone else.
regarding the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug and SOFTWARE\WOW6432Node\Microsoft, I could only change the Auto value from 1 to 0 and it worked.:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
REG ADD "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
If you're running the same software on two machines and it's crashing on one(which is what's happening if the debugger is starting) then you probably have something else going wrong on your machine. It could be that you've got driver incompatibility issues, or that some of the other software you have installed on the machine has incompatible versions of dll's...
You need to try to eliminate as many of the differeces as you can (easier said than done, I know)... If you copy the contents of the CD onto a local disk, does that help? If you shutdown your virus checker while you install the software does that help? Does it help if you turn the network off? You've said that both machines have 'mostly' the same, software, what happens if you uninstall some of the differences? Have both machines been patched to the same level?
As Visual studio is trying to start up when you have issues, have a look at the call stack and see what dlls are loaded, print it out... run some of the other software that crashes on that machine and do the same thing... look for any common libraries and do a comparison between the machines to see if they have the same version of the libraries...
Of course it could also be that it's a hardware issue (I've had intermittent failures before now because one of my drives was getting ready to fail and others because my graphics chip was running too hot)...
As I said, not really an answer, but some things to consider...
If all else fails... you're probably stuck doing your bills on the other computer (although another experiment might be to create a VPC on the broken pc to see if it worked then)...
Right click on Project--Properties. Select the 'Web' tab. Under Debuggers, check 'Silverlight' (beside ASP.NET that is already checked).
Now visual studio won't debug your javascript because fortunately it can't debug Silverlight and javascript at the same time. You can now attach your javascript to the browser debugger.
This problem was appearing when I started pdf viewer. I reinstalled this program in other folder (another disc in comp) and in my case it worked.
Related
Occassionaly, but fairly often, for no apparent reason, VS 2012 will lock up with a dialogue that says, "Waiting for a background operation to finish". E.g. this may happen during a plain old code edit, not on explicitly invoking any IDE command.
What causes this, and is there anything I can do about this?
I am running ReSharper 7, and I am not the only one I know experiencing this.
I was having the same problem, especially in cshtml pages. I found this page: https://devblogs.microsoft.com/aspnet/visual-studio-11-beta-razor-editor-issue-workaround that suggests changing the indent option in Tools > Options > Text Editor > HTML > Tab to Smart instead of Block. In my case it was already set to Smart and changing it back to Block fixed the problem.
Update: I was wrong, that didn't fix the dialogue, it just delayed it until I copied or pasted. What finally worked for me was to go to Tools > Import and Export Settings... > Reset all settings.
Possibly related question: Visual Studios 2010 - Asp.net MVC 4 Beta - long delays on paste and frequent crashing
It is a very generic diagnostic. It is triggered by COM, heavily used in Visual Studio to implement extensibility. The underlying trigger is the IMessageFilter interface. The trigger occurs when COM marshals a method call to another thread and that call doesn't complete for 60 seconds.
There's little value in the actual notification, it is telling you something you already know. By the time 60 seconds have passed, you typically already have noticed things are not working well. Short from the wee bit of useful knowledge that Visual Studio isn't actually completely dead. The call however has to complete before VS gets usable again. There's little you can do but tap your foot and wait.
This problem is almost always caused by an add-in. Resharper is certainly a good candidate. You find the trouble-maker by disabling the add-ins one-by-one until the problem disappears. It is the kind of problem that's common with new versions of Visual Studio, it takes the add-in vendors a while to get the bugs and hangups ironed out. Contact the vendor for support and in general look for updates that may solve the issue.
Deleting the Solutions "suo" file worked for me.
I was having the same problem and in my case it was DevExpress.
It seemed to hang Visual Studio everytime I did a copy or cut operation, bringing up the message:
"Waiting for a background operation to finish".
Turns out it was actually doing a one off task in the background and it really was taking a while to do it (over 5 minutes).
Perhaps if I had waited normally, it could have gone away, but what finally fixed it was to bring up the Toolbox into view (was hidden/collapsed), which in turn brought up a window saying:
"adding [SomeDevExpressAssemblyNameHere].dll"
this kept updating itself with the name of every dll required by DevExpress to populate the toolbar.
This way I could see the operation progress and after it finished I could use copy/cut paste again as usual.
Hope this helps.
For me the fix was to update the Web Essentials 2012 to version 1.8.
The problematic version was 1.6
Tools > Options > Text Editor > HTML > Tabs -> Identing -> None settings solved this problem for me.
This fixed it for me:
Tools > Options > Text Editor > HTML > Miscellaneous
Uncheck the option "Auto ID elements on paste in Source View"
I will post an update if the problem comes back.
I had this problem for a couple of days, tried uninstalling and reinstalling my visual studio 2012 ultimate edtion SP3...
Still didn't work.
So I deleted all my extensions (git tools for VS 2012 and Nuget Package downloader),
restarted my VS and it worked liked a charm again!
Hope it works !
Good luck!
I experienced this problem while running visual studio in a virtual machine - Virtual Box 4.2 running on Mac OS X Mountain Lion, hosting a fresh Windows 7 install with nothing else installed but Visual Studio. I found that the problem was caused by 2 separate issues.
Firstly, my project was on a folder shared from the host OS. In other words, on the Windows Guest, my project appeared on a network drive. So opening the project in Visual Studio from a network drive seemed to cause this problem because the problem went away when I copied the project onto the C drive of the Windows VM and opened it in Visual Studio from the copy on the C drive.
Secondly, I began to experience the problem again when the hard drive on the virtual machine was getting full. I had about 1GB free space available on the hard drive. When I increased the size of the hard drive on the virtual machine, this issue went away.
Just reproduced similar problem with Codemaid add-on. Found this conversation:
There's a lot of details in this issue, but to try and recap the issue
is that the VS2012 C++ API introduced a deadlock issue when the API is
accessed from a UI thread (e.g. a WPF context like Spade). It wasn't
an issue in VS2010, and Microsoft has fixed it going forwards for
VS2013 but they will not be patching it for VS2012.
Seems to indicate that a fix (for Codemaid) should be coming:
Please keep an eye on this thread for the ongoing resolution of the
issue. It ties in to that larger rewrite so I've been building towards
it by adding a lot of unit tests first to help ensure functionality
remains consistent after the changes.
For me it seemed to be related with the razor syntax, since I only had it on one particular file.
For example if I put the following code in one line I had the described issue.
#section BodyClassName {note}
But when putting the closing parenthesis on the next line the issue went away
#section BodyClassName {note
}
Kind regards
Stijn
Far from an ideal solution, but please trying running visual studio in administrator mode
i tried virtually everything, and this was the only thing that worked for me
Open Visual Studio, create a new MVC application, close the new application, open the old application and it works!
Check if IIS or another process (BizTalk maybe) is locking your DLLs/references
Kill/stop IIS or the other process if it is
http://geekswithblogs.net/sevenfortytwo/archive/2006/11/23/97947.aspx
RUN> iisreset
Now it is working fine with VS 2012
i think i have found a clue! Every thing is ended to dcomcnfg.exe!
Open it and go under following path:
Component services>computers>my computer>dcom config
after click on dcom you'll see many warnings depend on amount of components on your pc.
Click yes on each message box in order to add correct record for dcom.
I found that VS also loads packages during the "background operation". You can remove unneeded extensions to make the operation faster.
I have it fixed weeks ago after I turn TeamViewer 8 Clipboard Sync off! now it appears back with no reason so I tried reset all settings and it worked for me.
I was having the same problem and running VS as an administrator seems to have done the trick for me (I had posted a similar question at Visual Studio 2012 Express Hangs with Message "Waiting for Background Operation to Complete" on Format Document Command that was marked as a duplicate for this one so I figured I would share here as well).
For me, it was Resharper addon opening a dialog which didn't show. I only found the dialog icon in the hidden icons menu on the task bar. When i got rid of the dialog, Visual Studio returned to normal immediately.
Not to bore you, I'm gonna make long story short. Two machines, identical systems on them, identical programs (mostly). One has Visual Studio installed, one has ... uhmm, something else.
Sometimes when I try to install applications from let's say a CD, Visual Studio's Just-In-Time Debugger pops up, reports an "unhandled win32 exception in ..." and asks whether I want to debug using "New instance of Microsoft VIsual Studio 2010". If I choose Yes, it runs VS, if I choose No it closes the thing, and I'm back in Windows Explorer.
Which would be ok, except I know the application is perfectly all right, and this way I cannot install it (in this latest cast it was the client from my bank for internet banking and paying bills and such).
So, how do I get rid of that thing (just-in-time debugger)?
I don't want to uninstall VS since I'm using it daily, of course.
Edit 1 :: I tried disabling Just-In-Time debugging in VS's Tools/Options/Debugging/Just-In-Time, then unchecking all three checkmarks, but that just gave another error when trying to run the executable installation program.
An unhandled win32 exception occurred in autorun.exe [some number]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time debugging can be enabled from ...
Check the documentation index for 'Just-in-time debugging, errors' for more information.
Very informative :/
Edit 2 :: The application runs fine on the other machine that doesn't have VS installed. To a large extent software on both machines is the same, with just some minor differences (systems installed from image). Minor differences: notepad2, ++, git, ... some small stuff that is left to dev's own choosing.
I don't want this to sound as rant against VS, since I realize it's taking that tone, but I extremelly dislike software that is not self contained and messes other software up. And I had the same problem before with other applications as well. So for now, I'm blaming VS.
If necessary, I'm willing to disable all kinds of debugging for this thing to work permanently (mostly use print statements anyways), if that will help. And if it possible.
I just had this problem today with Visual Studio 2013. This MSDN article:
Just-In-Time Debugging in Visual Studio works for me. In my case, I just rename Debugger to Debugger_del and DbgManagedDebugger to DbgManagedDebugger_del.
To disable Just-In-Time debugging by editing the registry
On the Start menu, search for and run regedit.exe
In the Registry Editor window, locate and delete the follow registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
If your computer is running a 64-bit operating system, also delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Take care not to accidentally delete or change any other registry keys.
Close the Registy Editor window.
I am adding this response even though this is an old topic because I have just spent most of the day on this very issue and finally solved it. Every solution I found focused on disabling or turning off JIT debugging in Visual Studio, deleting keys from the registry or changing IE script debugging settings. But if you don't have a registered copy of VS, you have a problem. Of course, many of the solutions work in different ways but then you are left with the error above "no installed debugger has just-in-time debugging enabled" which no-one seems to have an answer for. However, the answer is not to disable JIT but rather stop server side debugging in your application. Unless you actually want to do server side debugging it is not necessary for it to be on.
It makes complete sense to me now because I had server side debugging turned on in ASP. Before installing VS, it made no difference because no debugger was assigned to handle the bugs so they were sent to the browser. Once I installed VS, JIT took over and did what tit was supposed to do.
So the quick answer, open IIS, click on default sites or your sites and in your application settings, ASP in my case, turn off server side debugging!!
It may not be everyone's answer, or even the solution to the above problem, but hope it provides more insight to this problem and help someone else.
regarding the key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug and SOFTWARE\WOW6432Node\Microsoft, I could only change the Auto value from 1 to 0 and it worked.:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
REG ADD "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug" /v Auto /d 0
If you're running the same software on two machines and it's crashing on one(which is what's happening if the debugger is starting) then you probably have something else going wrong on your machine. It could be that you've got driver incompatibility issues, or that some of the other software you have installed on the machine has incompatible versions of dll's...
You need to try to eliminate as many of the differeces as you can (easier said than done, I know)... If you copy the contents of the CD onto a local disk, does that help? If you shutdown your virus checker while you install the software does that help? Does it help if you turn the network off? You've said that both machines have 'mostly' the same, software, what happens if you uninstall some of the differences? Have both machines been patched to the same level?
As Visual studio is trying to start up when you have issues, have a look at the call stack and see what dlls are loaded, print it out... run some of the other software that crashes on that machine and do the same thing... look for any common libraries and do a comparison between the machines to see if they have the same version of the libraries...
Of course it could also be that it's a hardware issue (I've had intermittent failures before now because one of my drives was getting ready to fail and others because my graphics chip was running too hot)...
As I said, not really an answer, but some things to consider...
If all else fails... you're probably stuck doing your bills on the other computer (although another experiment might be to create a VPC on the broken pc to see if it worked then)...
Right click on Project--Properties. Select the 'Web' tab. Under Debuggers, check 'Silverlight' (beside ASP.NET that is already checked).
Now visual studio won't debug your javascript because fortunately it can't debug Silverlight and javascript at the same time. You can now attach your javascript to the browser debugger.
This problem was appearing when I started pdf viewer. I reinstalled this program in other folder (another disc in comp) and in my case it worked.
it starts up windows installer with random applications on my machine . . after i click cancel a few times, it loads vb6 fine.
any ideas why this is happening?
To stop this behavior:
Start VB6
Open the Add-Ins dialog
Uncheck the "Visual Component Manager" Add-In
Source:
After VS2010, SP1, VB6 launches VS2010 installer
This is what a Windows Installer repair looks like. It means that something is broken in one of the installed products on your system. Ideally it's a one-off repair so you might be better off letting it runs its course and do the repair, except of course if it asks for a install CD that you don't have.
The Windows event log (Application) will have MsiInstaller entries saying what product and component has the problem.
It's possible a previous installation has not completed correctly.
Use the utility at the following link to remove any rogue installations files:
http://support.microsoft.com/kb/290301 (broken link Aug.2017, leaving URL for "historical purposes").
As PhilDW has pointed out this is a Windows Installer Self-Repair issue, and can often be resolved by allowing the self-repair to complete once. At other times the problem persists and it should be fixed by other means. Even when the self-repair completes and the problem goes away, it can still resurface once you launch the conflicting application. Windows Installer is not easy to deal with.
In your particular case you might be able to get away with a "workaround" rather than a fix. By locating the main VB6 EXE file on disk (in its main installation directory) and manually creating a shortcut to it on your desktop, you might be able to successfully launch VB6 via this new shortcut without the self-repair kicking in. It might be worth a try.
This shortcut trick will not remove the underlying problem, but might help to "bypass it". Just for the record: the reason this might work is that the new, manually created shortcut is not "advertised" and will not trigger a key-path check of the installed product when launched. This is Windows Installer's way to verify that a product is correctly installed. Note that even if the workaround works, self-repair might still result during application use because of faulty COM data being detected (which is very likely the cause of the whole problem you are seeing, but give the manually created shortcut a try).
There is a rather comprehensive "article" on self-repair here: How can I determine what causes repeated Windows Installer self-repair? which might help to track down the cause of the self-repair kicking off in the first place, but fixing it can be a rather complicated process (so try the workaround first). It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop. The last application to launch will overwrite the registry or file system with its own setting.
This worked for me, for VS2010 RC:
"Please wait while windows configures Microsoft Visual studio 2010 Ultimate."
THe work around that fixes the issue for me was to run the following via the admin cmd prompt.
Md "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\common7\IDE\FromGAC"
from http://social.msdn.microsoft.com/Forums/en-SG/vsprereleaseannouncements/thread/572a0f8a-16b0-4e1d-b581-16be36a9b564
This was also happned to me.
Whenever i tried to open vb6, it started windows installer to configure "Autocad".
Autocad had not broken. and it was working fine.
I tried removing and reinstalling Windows Installer, But it did not solved the issue.
Then i installed Microsoft's "Windows Installer Clean Up Utility 2" from given link.
Using this utility i removed the autocad from "Windows Installers" Database.
After that VB6 never started installer again.
Keep in mind 'removing any entry from installer's database may be risky, but i had no choice. So do it on your own risk.
Download "Windows Installer Clean Up Utility 2" (this is a deprecated, unsupported and unsafe tool to use - Aug.2017. I will leave the link in for "historical purposes", don't use it).
I have a VB6 app that formerly worked perfectly on a Vista machine as a scheduled task, but it will no longer open on the same machine. The app generates export files in a specified folder with no direct output on the screen. I get no errors, no missing references, just absolutely nothing.
The machine is running Vista Business 32-bit, UAC is disabled with a single administrator account, and automatic updates are turned off. The app resides in a non-protected folder, and the export files are put in a folder on the desktop. The client swears that the only change they made to that computer since I installed this app was installing Norton Antivirus, which has never caused problems before with our software.
In addition to the normal VB6 references, the app references Microsoft Scripting Runtime (scrrun.dll), and Microsoft DAO 3.6 (dao360.dll). Both of these files are present and registered on the target machine, along with all the other VB6 dependencies. I added MsgBox statements at the beginning of Sub Main() just to see if anything is being executed, and its not. Disabling Norton yielded no results, nor did reinstalling VB6 runtime to rule out any corrupted libraries. Not once did I get any messages, error or otherwise from my app.
I've never had an issue like this before and I'm completely stumped. Is there anything else that could be causing this?
Edit - The app does not run even when I run it manually, so the part about it being a scheduled task is irrelevant to my problem, sorry for including it.
The user has full administrator credentials, no compatibility mode was needed on the initial test which at the time, was done on this very machine I am having the problem on. For grins I tried compatibility mode for XP and 2000, still nothing.
Try to inspect - if you can access them - the Event Viewer messages. Maybe you will find some tell-tell signs in there...
You could try running the program in Windbg, a free standalone debugger from Microsoft. Compile your VB6 EXE into native code with symbols (create PDB files) and you will be able to debug your application in Windbg.
I would guess one of two things will happen.
Windbg will fail to load the EXE. Presumably with an error message that will identify your problem.
Windbg will load the EXE, and you can single-step through to see what happens.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
Has the user changed their password? That will cause the scheduled task to fail until they re-enter the password on the task.
Have you tried running the process directly, instead of as a scheduled task? I'm far from an expert, but it may be that any errors being generated are not showing up because the program is running as a task.
In Visual Basic 6, when I attempt to access Project > References, it throws an error:
Error accessing system registry
I am:
Logged in as the local computer administrator
running Windows XP Professional and
I can execute regedt32.exe and access all the registry keys just fine.
VB6 was installed as the local administrator.
Any idea why this happens?
I'm running crystal reports 8.5 and it supposed to already have fixed that issue but apparently I still have the issue with 8.5 installed. I have also made the attempt of reinstalling crystal reports with no luck on the issue.
Depending on the Windows OS you have (I have Windows 7 Enterprise), you might want to try giving administrator rights to the REGTLIB.EXE (located in C:\Windws). Right click on the REGTLIB.EXE file. Select Properties from the pop-up menu. Then select the Compatiblity tab. On the Compatiblity tab, check/select the Run this program as Administrator checkbox. Click OK to save your changes. It might take take care of the problem for you. It worked for me. Good luck.
For me this worked:
goto C:\Program Files\Microsoft Visual Studio\VB98
change the property of VB6.EXE by right click->Compatibility In privilege level section, check the option Run this program as Administrator
If you're running Office 2010 (Beta) Word (apparently) writes a restricted registry key. VB throws the error when scanning the registry. The key I have is:
HKCR\TypeLib\{00020905-0000-0000-C000-000000000046}\8.5
For Regmon - Filter for Process Name -> "vb6.exe" and Result -> ACCESS DENIED. Helps find it very quickly.
Fixed it with PSToosl (PSEXEC) to run registry editor. The command line is,
psexec -i -d -s c:\windows\regedit.exe
psexec needs to be run with elevated-permissions.
Edit by Jim: I'm on a Windows 7 (x64) box. Elevated permissions require the PSTools solution. XP can get away with a little less.
You could try Process Monitor to see which registry keys are accessed.
I got this on a machine that I was using for VB6 development. I had been building a lot of COM DLLs from VB6 (without binary compatibility) and the cruft that had built up in the registry eventually got too much.
Have a look at what size the registry is and what limit you have set. I doubled the registry size and then went looking for a good registry hoover.
Here is a solution from Microsoft. It references the Crystal Reports problem, but the solution just uses regedit32 to walk the HKEY_CLASSES_ROOT\TypeLib and HKEY_CLASSES_ROOT\CLSID registry branches for dimmed keys and correcting the security on those keys. There are also instructions to fix the security if regedit32 is unable to access the key. Article ID: 269383
In Windows 7 go to start menu then right click "Microsoft Visual Basic 6" then select properties and click Compatibility from the dialog box that appears then tick "Run this program as an administrator".
Have you tried this? Basically, it seems that it is a crystal reports issue. Hope that helps.
Perhaps worth a try going to the "User Account Control Settings".
Regards,
When I installed VB6 on Win7-64 (using instructions easily found by a search engine), it worked fine. UAC was off -- i.e. set to "never notify."
After a few weeks I turned UAC on -- i.e. set it to its default. VB6 then couldn't compile because of the "Error accessing the system registry" problem. Unfortunately, turning it off again didn't help. Apparently the damage done by turning it on was irreversible. I can't explain why this should be, but that's my experience.
Giving REGTLIB.EXE administrative privileges while leaving UAC off sounded like a great idea, but that didn't work for me either.
Finally, using Process Monitor and PsTools as described in other posts here worked. However, I had to give Full Control to large parts of my registry to Everyone. This didn't apply just to isolated keys. It seems that the compiler needs to add keys to major nodes, so I had to open up these entire nodes.
Aside from the fact that working through these steps took hours, I'm now much more exposed than I was before I tried to increase security via UAC, However, I need VB6 and don't see another solution short of a new computer.
Lesson: Don't use UAC with VB6. Except if you've arrived here it's too late for that.
It's VB6 installation issue. Try to re-intall VB6 on your system. Otherwise open "visual studio 6.0" with "Run as Administrator". Then open/browse your project .vbp file via - New Project -> Existing tab.
I have fixed the problem. But none of the suggestion above worked. What I did is giving everyone full control over the SYSTEM key in the registry. This creats a security break. I am running 64bit Windows 7 with vb6 serice pack 6B.
I'm running Windows 10 Pro (10.0.16299 Build 16299) 64 bit. I was having this error when trying to compile a VB6 DLL.
I saw several answers in this post about running in compatibility mode as administrator. I thought I would first try just running in compatibility mode for Windows XP (sp2). I was able to compile my DLL after checking that box. I didn't need to run as administrator.