My software (with admin priviledges) periodically performs the following query via WMI to know the status of the CPU:
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_PerfFormattedData_PerfOS_Processor");
ManagementObjectCollection collection = searcher.Get();
Suddenly (meaning after months where the result of searcher.Get() was always available) the command started sitting down and throwing an "Invalid query" Exception after a timeout. I cannot say what's changed in the machine before this happens.
I confirmed this error by testing it with tool wbemtest:
The error happens everytime, even after reboot. How can I debug it?
System is Windows 10 x64 IoT Enterprise v1607.
The solution is explained in this article.
Anyway, I still have not understood the reason why the counters may get corrupted. Any comment on this?
I ran into this issue on a Windows 7 machine separate from a network and required to be kept around for various reasons.
At first I thought it was an admin thing (the program runs as a normal user) because system event viewer error 2011 hints at that.
However, it's fixed with this:
lodctr /r
I don't fully understand why, but this article was my source:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/4d574e10-17f5-4599-95d6-2492ede3cfef/wmi-query-from-net-application-cause-2011-error-event?forum=netfxbcl
My company finally upgraded our development team from Windows XP to Windows 7 64-bit computers and I just discovered an odd error with existing code in the new environment. The project in question references a COM library that's used to interact with our document image management system. Any attempt to initialize an instance of this API's Library class is now throwing an SEHException. The error code returned has not been informative. Here is the full Exception from a stripped-down sample project I wrote to test this problem:
System.Runtime.InteropServices.SEHException was caught
ErrorCode=-2147467259
HResult=-2147467259
Message=External component has thrown an exception.
Source=FileNetTestLib
StackTrace:
at FileNetTestLib.Library.Logon() in C:\Projects\Tests\SEHException\FileNetTestLib\Library.vb:line 4
at SEHException.Form1.btnLogIn_Click(Object sender, EventArgs e) in C:\Projects\Tests\SEHException\SEHException\Form1.vb:line 7
InnerException:
While working with my sample project I was able to confirm the following:
The Exception only occurs when debugging; running without debugging does not throw any exception
The Exception DOES NOT occur when debugging on Windows XP (tried on two Win7 and two XP computers)
The Exception DOES NOT occur when we change the target framework to anything lower than .NET 4. It only occurs on .NET4 or higher.
So to summarize, the error occurs if we are debugging on Windows 7 targeting .NET4 or higher. It does not occur if we change any one of these factors.
In researching this I discovered that .NET4 changed its security model for how it handles exceptions thrown from non-managed code. It looked at first like this might relate to the issue, but from what I've managed to learn so far, the changes affect only a subset of SEHExceptions and apparently not the one I am getting because (1) I am able to catch the SEHException in a try...catch block where the change in .NET causes the affected exceptions (corrupted state exceptions) to not be caught by .NET at all unless you make certain changes to your code or config file (which I have not made and have confirmed are not present in my project) and (2) the problem is only occurring for me under Windows 7 and I haven't found anything to indicate that these changes in .NET4 were Win7-specific.
FYI, I don't have a 32-bit version of Win7 so I can't confirm if the issue is specific to Win7 64-bit or Win7 in general. I AM compiling the project as x86 since I cannot compile it as x64 due to the COM component. I have also tried this on VS 2013 as well as VS 2010 and get the same results on both.
Since the problem only occurs while debugging I checked which Exceptions I am allowing the debugger to break on (hoping it was selected and I could just uncheck it to get the debugger to ignore it) and SEHExeption is unchecked (under Debug|Exceptions). I also checked the Debugging options in VS and "Break when exceptions cross AppDomain or managed/native boundaries" is unchecked. Changing either of these has not made a difference.
I also tried initializing a completely different COM component (ImageMagick, in this case), to make sure the error wasn't occurring for ANY COM component but I did not encounter any problems with that. I am about to contact the vendor of the COM component that is causing an issue for me, but I was wondering if anyone else has encountered any similar problem with other COM components and if so if there's a way to prevent or ignore these types of errors when debugging since the error only appears to be generated as a result of running in the debugger.
I have noticed that about every third time or so I start up the VB6 IDE, a message box appears with the following error message:-
Method '~' of object '~' failed
This doesn't happen for any particular project or with any other thing in common that I have noticed. It doesn't appear to cause any problems after dismissing the message. My question is: ought I to worry about this, and if so, what should I do about it.
I have noted these other questions about the same error message here, here and here, but I get the message on opening up the project.
This is usually caused by locked clipboard on local machine. VB6 IDE add-ins use clipboard to copy/paste icons to toolbar buttons because the add-in API does not expose any other way of putting an image there.
Usually Remote Desktop client (mstsc.exe) is the culprit of the locked clipboard. The way Microsoft implemented transfer to remote clipboard is by probing local clipboard for available formats which locks it for a while. Clipboard is awfully designed global resource that can be accessed by a single process at a time and OpenClipboard API fails in flames for other processes if the resource is not currently available.
I used to occasionally run into this error and, in my case, it was caused by the Visual Source Safe add-in (bad install I guess; re-install corrected the issue). It never caused a problem; it was just a bother. As Jon stated in the comments, I would try shutting off add-ins to see if that fixes the issue. Another thing is to make sure you are running Service Pack 6.
I don't know about this specific error, but I do have some background information about this error message.
COM defines two levels of error information. All COM methods and properties have a return value with the type HRESULT, where 0 (S_OK) indicates success and negative values indicate an error. In addition there is a mechanism to provide so called "rich error information".
If a COM object generates rich error information, VB6 will show the information provided. If a COM object returns a negative value, but does not provide rich error information, then VB6 shows the message “Method '~' of object '~' failed”.
There are some standard error codes like E_POINTER and E_NOTIMPL which are often returned by COM objects in C++. All of these result in the message “Method '~' of object '~' failed”.
If you are implementing a COM object in C++, my advice is to always generate rich error information. (In ATL you just have to call the Error function.)
I uninstalled Visual Studio 6.0 and then re-installed it. This cleared the “Method '~' of object '~' failed” error for me. My VB 6 now appears to be functioning properly. I believe that, in my case, it has to do with several of the COM objects not being registered properly. My new machine received a ghost image from my old box which had VS on it.
I started getting this error all of a sudden on both of my development machines (one 32-bit, the other 64-bit). In my searching for a solution, someone made a tangential reference to SourceSafe.
Ahh, then it occurred to me that I had been recently cleaning up a project (clearing out .bak files, etc.), and one of the files I cleaned-out was 'MSSCCPRJ.SCC' (seeing how SourceSafe was - for our group - a distant relic, I felt "safe" removing this file from the project folder).
Long story short: restoring the file 'MSSCCPRJ.SCC' to the project folder, resolved this error.
I just came across this error while running VB6 on Windows Server 2012 R2. The offending Add-In was Visual Component Manager 6.0. Once I disabled that, the IDE was able to open without the Method '~' of object '~' failed issue. I'm not sure if that points to an installation issue or just "ancient" software on a "modern" OS.
For anyone else trying to install VB6 on Windows 7, 8, 10, 2012, etc., here are some useful links:
http://www.fortypoundhead.com/newbrowseresults.asp?catid=34
http://it.toolbox.com/blogs/locutus/how-to-install-visual-studio-6-onto-windows-10-70155
I just had the same experience when starting VB6 on my Windows 7 Ultimate desktop PC via a shortcut to a VB6 project (which, of course, starts VB6.) The notification box was titled "Visual Component Manager" and the message was "Method '~' of object '~' failed". It occurred when first starting the VB6 IDE, before the project was visible in the IDE. I have been using this process with this same project for several years with no issues, but today that message box popped up and had to be acknowledged. The one thing that I did differently today, and I believe this caused my problem, was to start an Excel 2007 workbook first and then start the VB6 project about three seconds later. Both were loading at the same time and they were probably battling each other for something they both needed. Starting my VB6 project by itself never results in this. Looking at all these responses, the one common thread seems to be that VB6 is unable to access some resources when they are needed. None of the responses suggest it is a serious problem; in fact, it appears to be simply a minor 'hiccup' until such time as the resources are freed.
I found the ultimate solution!
To avoid the "Method '~' of object '~'" message and avoid any "Windows Installer" message from running at startup of the VB6 IDE:
via the VB6.exe properties (after right-clicking on the file in Windows Explorer), ensure that VB6.exe has compatibility set to "Run in Windows 8" mode.
Ensure that the VB6.exe shortcut is set to NOT run as an Administrator.
With these settings it is OK to load any of the Add-Ins (including Visual Component Manager 6!)
It took me ages to work this out, but now VB6 loads with lightning speed and no annoying error messages.
private void button1_Click(object sender, EventArgs e)
{
///IDE will notify me of this exception
throw new Exception();
}
private void Form1_Load(object sender, EventArgs e)
{
//IDE will not notify me of this exception
throw new Exception();
//code will not execute
MessageBox.Show("test");
}
why?
----------------------EDITED----------------------
the correct answer is what ChrisA mentioned.
some quotes from microsoft :
This is a known bug with x64 versions
of Windows and the way exceptions are
handled. One way to work around this
issue while debugging is to go to the
Debug -> Exceptions and select
'Thrown' for for the exception types
you are interested in. This will stop
the debugger when the exception is
first hit (and before Windows eats it
up).
This bug was closed as "External"
because this behavior results from how
x64 version of Windows handle
exceptions. When a user mode exception
crosses a kernel transition, x64
versions of Windows do not allow the
exception to propagate. Therefore
attached debuggers are unaware of the
fact that an exception occured
resulting in the debugger failing to
break on the unhandled exception.
Unfortunately where is nothing that
the Visual Studo team can do to
address this, it is the result of
operating system design. All feedback
regarding this issue should be
addressed to the Windows team; however
the Windows team considers this to be
the "correct" operating system design,
and considers the x86 behavior to be
"incorrect".
This hotfix has not undergone full
testing. Therefore, it is intended
only for systems or computers that are
experiencing the exact problem that is
described in the one or more Microsoft
Knowledge Base articles that are
listed in "KB Article Numbers" field
in the table at the end of this e-mail
message. If you are not sure whether
any special compatibility or
installation issues are associated
with this hotfix, we encourage you to
wait for the next service pack
release. The service pack will include
a fully tested version of this fix. We
understand that it can be difficult to
determine whether any compatibility or
installation issues are associated
with a hotfix. If you want
confirmation that this hotfix
addresses your specific problem, or if
you want to confirm whether any
special compatibility or installation
issues are associated with this
hotfix, support professionals in
Customer Support Services can help you
with that.
Are you developing on an x64 machine?
If so, you might like to have a look at this.
That thread also refers to a very detailed explanation of the whole issue.
This, and another show stopper (for me anyway, the workarounds didn't work for me, or my colleague) on x64, resulted in a rebuild of my dev box with win7 x86.
The problems have all gone away now. But it's very disappointing.
A known bug with a Windows XP security update KB978037 can occur with Visual Studio 2005 (and 2008) where sometimes if you restart a debugging session on a console app then the console window doesn't get closed even though the owner process no longer exists. The problem is discussed further here:
Visual studio debug console sometimes stays open and is impossible to close
These zombie windows then can not be closed via the Taskbar or via the TaskManager, and typically require a power off/on to get rid of them. Over the period of even a single day you can accumulate quite a few of them, which clog up your TaskBar and are generally annoying.
I thought I would knock up a simple C++ Win32 utility to attempt to call DestroyWindow() on these windows by passing the windows handle as a cmd-line argument and converting it to a HWND.
I'm converting the handle from a string by parsing it as a DWORD then casting the DWORD to a HWND. This appears to be working as if I call GetWindowInfo() on the handle it succeeds. However calling DestroyWindow() on the handle fails with error 5 (access denied), presumably because the caller process (i.e. my app) doesn't own the window in question.
Any ideas as to how I might get rid of the zombie windows, either via the above approach or any other alternative short of rebooting? I'm in a corporate environment so installing/uninstalling updates/service-packs etc isn't an option.
Microsoft's hot fix for Windows XP and Windows 2003
I know this is not what you want to hear but the only way to get rid of these windows is by rebooting the computer
Apparently the windows team is trying to fix it:
http://blogs.msdn.com/debugger/archive/2010/03/11/help-my-console-windows-won-t-go-away.aspx
but not much seems to be happening
This issue is still a problem with Visual Studio 2010 on Windows 7!
See this thread