So I’m working at home yesterday, using the Visual Studio 6.0 VB debugger, plugging away at some code, and I start the debugger so I can walk through some buggy code that I wrote. I get this message:
I’m like whhhaaaaaaaaa? Never seen it before. And I only get it when I try to debug dll’s or ocx’s, exe’s work fine. So I go to microsoft’s “knowledge base”, and it said that I either had a bad entry in my registry (I didn’t), or to reinstall client networking. What??? That doesn’t make any sense.
So I mettle with it some more, but the pesky problem still persists.
So I go into work today (yes I occasionally work sundays), and try the debugger, and it works just fine!
So I figure it must have something to do with the fact that I was dialed in thru a VPN on saturday, and sunday I was actually at my work machine. I bet one of those stupid useless security patches that they make you install did this, it must have thought I was an intruder trying to randomly run com objects (even though i was authenticated correctly).
Useless security. If I can’t use my debugger, how can I be expected to sit in my basement and write code without wearing pants?
I had the same problem you had and the same solution. Thanks I was totaly stumped. Now when I attempt to debug the web app athat calls my COM object gets “Permission denied”. It works when I am not trying to debug. Whats up with that?
This problem is particularly nasty, no doubt. Want to know what I found out? If I leave work, and reboot my computer before I leave, I get the problem (consistently). If I DON’T reboot my computer before I leave, and at some point before my last reboot I ran the VB debugger logged in directly to my workstation, I won’t get the problem at home. It’s the weirdest, stupidist, most annoying thing ever. Just never reboot your computer, and you won’t ever have a problem. ha.
i know that this is an old post, but i thought you might be interested to know that there is a much easier fix for this problem. log out of the computer and back in as another user, preferably as an administrator though im not certain it makes a difference. run your dll and run something that accesses it to make sure that all of the registry entries related to debugging are cleared and replaced with settings for the new user. when you log back in as yourself, you should be able to debug as normal. if you check the event log you may see some entries, as well, related to unsuccessful unloading of the registry that help explain why this works.
thanks — your post helped me get on the right track!
I had the same problem and here’s the easiest answer: when you remote access your workstation, run this from the start button: “mstsc /console” and then log in as normal. Then, when you start VB remotely, all will be well. You need to have a console session running, and if you reboot and remote access your workstation, you won’t ever get one started. COM services packages run in the context of the console.
Thanks for the advice. I’ll try that next time the problem creeps up.
hi
i have gone thro the suggestions which the previous friends gave
but i am unable to work iwht debugger and its throwin the same error box
becoz i have done my project in Admin login of XP
plz help me regarding this
I had this problem and temporaily fixed it by changing the identity of the package my dll was in to “System Account: Interactive User - The current logged on user”, rather than the application user it had been set up as.
Hope this fixes someones problem somewhere!
Thanks Jamie, your suggestion solved my problem, I was working on the VM and not accessing the application remotely.
I had the same problem. I was trying to run a COM+ component in debug but the DLL was already set up in a package in Componenet Services. I just removed the component from the package and now debugging works fine.