Thank you for your reply and comments.
Let me describe the situation more detailedly.
I use Visual C++ 2008 to write a small application that will invoke MAPI. I use MAPIStubLibrary to support both 32bit and 64bit MAPI. MAPIStubLibrary can be found at https://msdn.microsoft.com/en-us/library/office/cc963763.aspx#sectionSection2 . It works on other versions of Outlook and most of the systems. However, under Windows 10(32bit) with Office 2016(32bit) installed, when I execute the following statement to initialize MAPI:
MAPIInitialize(NULL);
I will get the above error message "The operating system is not presently configured to run this application". And there will be an unhandled exception raised from the function GetDefaultMapiHandle(), which is in StubUtils.cpp, part of the MAPIStubLibrary.
The exact line that cause the exception is:
hinstMapi = LoadLibraryW(wzPath);
It seems that MAPIStubLibrary is trying to load 32bit MAPI but fails. wzPath is pointing to olmapi32.dll instead of msmapi32.dll.
In the error message, if I click “OK” button in the error messagebox, the application will continue running without problems. However, the error message is still frustrating and confusing the users. Therefore, how to eliminate the error?
Thank you very much.
This usually happens when you are either loading a wrong MAPI dll (e.g. olmapi32.dll instead of msmapi32.dll) or if your app is running in the compatibility mode (do you include a manifest?) and the MAPI system ends up patching wrong Windows API functions assuming an older version of Windows.
I'm working on an app in VS 2010 on wind2008. It's a .Net 3.5 app that use .Net 2.0 library.
I change all Frameworks to 3.5 .Net and uncheck "Enable the visual studio hosting process"
But When I debug my solution I got this error :
Problem signature:
Problem Event Name: APPCRASH
Application Name: AnalyseFarm.exe
Application Version: 1.0.0.0
Application Timestamp: 5326f157
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7600.16385
Fault Module Timestamp: 4a5bdfe0
Exception Code: c000041d
Exception Offset: 000000000000aa7d
OS Version: 6.1.7600.2.0.0.274.10
Locale ID: 1036
Additional Information 1: 5ecb
Additional Information 2: 5ecbd308407466ba89616cb69c9e62d8
Additional Information 3: 9ac0
Additional Information 4: 9ac06af1219db569f0ee193c24745b31
any idea , beast regards
Exception Code: c000041d
This tells the tale, that's STATUS_FATAL_USER_CALLBACK_EXCEPTION, "An unhandled exception was encountered during a user callback". Your program threw an exception and it wasn't handled. Which normally automatically breaks into the debugger and displays the Exception Assistant.
However, the exception occurred at a very awkward time, just when the operating system was in a state where it cannot afford to go through the normal rigamarole that it goes through when a thread dies with an exception. This kind of mishap usually occurs when the callback was triggered by 32-bit code but the exception occurred in 64-bit code, there's no good mechanism to marshal 64-bit exceptions back into 32-bit code, the exception information cannot be properly interpreted by such code since it includes 64-bit pointer values. Or the other way around. Windows messages generated by the window manager tend to fall in this category. Beware that this is just a rough guess at the reason, you need to find the real one.
You do so by forcing the debugger to stop at the code where the exception is thrown, before the operating system is asked to deal with it. Use the Debug + Exceptions dialog, tick the Thrown checkboxes to force the debugger to stop at the throw location.
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 keep getting random CLR exceptions while debugging which then causes the debugger to stop. It happens on my asp.net project and a blank asp.net project i created. Below is the error. Any ideas why? most of the time it happens while my app is idle or starting up
The runtime has encountered a fatal error. The address of the error
was at 0x71331c38, on thread 0x1928. The error code is 0xc0000005.
This error may be a bug in the CLR or in the unsafe or non-verifiable
portions of user code. Common sources of this bug include user
marshaling errors for COM-interop or PInvoke, which may corrupt the
stack.
or sometimes i get this one
System.ExecutionEngineException was unhandled Message: An unhandled
exception of type 'System.ExecutionEngineException' occurred in
Unknown Module.
Update
Im also having the same problem in VS2010 in a different project. They are both web based projects though. one is a set of WCF web services and the other is an asp.net mvc4 application.
Looks like i found the cause of the problem. I also noticed a few Access Violation errors and i was wondering if its because i'm running it inside VirtualBox. Did a quick search on Visual Studio in Virtual Box and looks like the Access Violation error could be caused by VirtualBox. So i used Disk2VHD and setup Hyper-V. So far no issues. I suspect the other exceptions might have been caused by VirtualBox as well.
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.