I am getting the "NotMarshalable recognized" error in my VB.NET application:
"A COM component which can not be marshaled is being using from a differrent apartement / context than the other it entered the CLR from. Because it can not be marshaled, it is correctly directly by the current apartement / context. This may lead to data loss."
The IDE stop in this line and offer "Get more information about MDAs" (which takes me to a website that explains MDAs). I have read through the website, but I did not find any information that help me explain which COM component is causing this error.
I can't read assembler, but I guess that all that I have here, right? ->
Can somebody tell me how to track down which COM component is causing this error and why? I have around 20 COM objects in my large project, and I can not rewrite all of them so quickly in .NET.
Thank you!
this is what I would try to do:
setup visual studio to stop on any exception
check what code is doing when the exception happen
check how the stack looks-like when the exception happen
use some .net decompiler to check what is happening inside the .net function that called the COM compenent
check the parameter of the function (by looking at the stack in VS) to try to understand which is the COM component
google any information found
Related
This question already has an answer here:
0xC0020001: The string binding is invalid. - Only occurring in WPF
(1 answer)
Closed 9 years ago.
I am trying to find a way to debug my application but it is very difficulty for me. The error is when I close the program, sometimes it shows the error code as below:
Unhandled exception at 0x7537812f in Sample.exe: 0xC0020001: The
string binding is invalid
My application is a windows form written in C# in Visual studio 2012 Professional and the program uses some native functions from a dll which is written in C. I researched on the internet but almost all solutions are not using static variables or compile the dll with /clr in Visual Studio for C++, but my dll is C code from third party and it is built by MingGW so I can't follow these solutions. To change the static variables is impossible.
Please help me to find the solution for it?
Without code it's difficult to say what is the problem. But when you say, the crash happens (sometimes) during the application is closing, you probably can't provide the right piece of code easily.
The reasons could be, some code of the program uses some data, which is already destroyed.
If the internal implementation of your DLL is C++ e.g. a destructor could access data already deleted or created statically before the instance of the class. This would be mean, the DLL causes the crash internally. For that explicite calling of some kind of close API function could be the only help.
Another cause is possibly, you instantiate the DLL in a C# class, which is destroyed in garbage collection. As the instances are destroyed "uncontrolled" they can call the already unloaded DLL API. A flag signaling the validity of DLL API would help for that cause.
So my suggestion are:
Check, If your DLL provides an API function for closing or cleaning
up or unloading - call it and don't call any other API-function from
DLL after that. Use e.g. a global flag tor that, and access DLL only
if the flag allows it. (poor man's approach, better - ecapsulate the
DLL in a C# class)
Try to load and unload DLL in any test-function of your C# for making
the error easier reproducible.
Make sure, when your C# begins the closing process not to call any
DLL function any more (except the once calling clean/close/unload)
Hope it helps.
I have a plugin that works on different boxes on different domains. However, I have it registered on one particular box that continues to throw this error every time the applicable entity event is triggered. The caveat? The code isn't even being executed. IE: The IPlugin.Execute() interface implementation is never reached. I just get the CRM dialog indicating "Invalid URI: The hostname could not be parsed." every time.
I've confirmed the code isn't being entered as I've attached Visual Studio to the applicable CRM processes. On the other boxes I can step in and through with no issues. This is how I determined the code isn't being reached.
The plugin has been registered in the CRM the same as it is on the other machines. I've placed it underneath a particular Solution file and published (even though that step isn't necessary).
Thoughts?
I figured it out. I also figured it would be idiotic in nature once I figured it out.
Summary: Unregister old, deprecated plugins.
Details:
This was a rewrite of a previously developed plugin (separate codebase), both of which are wrappers around a third-party web call. The third-party in question refactored their old-timey SOAP endpoint to a REST/JSON call. The SOAP call was officially taken offline on 1/15/13. AND...wait for it...the old plugins were still registered.
So, the error you see above was being thrown by the old plugins after the SOAP endpoint was officially deprecated.
The compounded problem? Since there were two IPlugin.Execute() interfaces wired to the same Entity.Event combination, I couldn't step into my code to debug. Now that the old plugins have been unregistered, it steps in immediately as expected.
The frosting on the cake? The execution of those two Execute() methods appeared to be completely nondeterministic. IE: Sometimes my new code would run (to a point), and sometimes it wouldn't. So either both Execute() methods were being run at the same time or one would be called before the other sometimes and vice-versa.
I won't soon forget this one. Thanks to all you guys who commented above. I actually attempted the fresh creation of an empty plugin, but it obviously rendered the same results. Hopefully this'll help someone someday.
I am experiencing an APPCRASH from my C# application. The Runtime gives an error message of "This application has requested the Runtime to terminate it in an unusual way". Then, when I click okay I get a "MyApplication has stopped working" message with the usual "check online for a solution", "close program" and "debug program" options. When I click "additional details" I get the APPCRASH signature, with lots of additional information. Some of it is human readable, some of it is just hex numbers. The "Exception Code" is 40000015. There are also lines of "Additional Information". My question is: does anyone in the universe know what the information in an APPCRASH message means?
It seems like the message was meant to be read by someone who can divine a cause from it. When searching for answers I found a lot of people posting messages formatted exactly the same. Unfortunately, I have found no explanations of what this information means.
Also, I have tried the "Debug Program" option, but it is unhelpful. It just puts me in system dlls with none of my code anywhere up the call stack. I've investigated, and the error doesn't occur in this system code.
The APPCRASH message named another dll as the "Fault Module" (this code uses a lot of external dlls), and the fatal error probably occurs there. But that information isn't very helpful because I need to find the place in my code that makes a bad call to the external dll (or puts it in a bad state). Sadly, when I say "my code" I just mean the code that I'm working with. It's a huge codebase written by several dozen people over a couple years, so I can't just guessing places that might make the fatal call. That's why I was hoping to divine more information from the APPCRASH message. That's also why I'm being very stingy with details. The whole thing is all very proprietary with lots of red tape. That's also why I haven't posted the APPCRASH message contents.
To be clear, I am not asking you to debug my problem for me. I have no way of giving you a reproducible case of the error, and I'm not asking anyone to tell me the cause of the error in my specific case. I just want to know how to interpret those hex numbers, and I haven't been able to find any documentation.
Here is an example of an app crash message:
Problem signature:
Problem Event Name: APPCRASH
Application Name: WINWORD.EXE
Application Version: 12.0.4518.1014
Application Timestamp: 45428028
Fault Module Name: StackHash_7ae5
Fault Module Version: 6.0.6000.16386
Fault Module Timestamp: 4549bdc9
Exception Code: c0000374
Exception Offset: 000af1c9
OS Version: 6.0.6000.2.0.0.256.4
Locale ID: 1033
Additional Information 1: 7ae5
Additional Information 2: 4cf2e59e469447e0692da79a5a9446de
Additional Information 3: 333f
Additional Information 4: 583336399425ab3efc33bdfbb60895ee
Application name and application version are straightforward, as is the timestamp (this is the changed date in File Explorer, encoded as a 32-bit Unix timestamp value). Fault Module is usually a dll name, and the exception offset is the offset address of the hardware instruction in the DLL that caused the error. In this case it was an internal runtime error where no valid module could be retrieved, so we got StackHash instead of a real value. The versions are the normal PE version strings of executable files in Windows. The locale ID is the globalization settings bank being used: 1033 is en-US.
The exception code can be interpreted here. In this example, the error was a STATUS_HEAP_CORRUPTION.
The additional information fields are opaque data, and based on what the exception code was. I do not know of any useful information on those fields, there likely isn't any, and it is likely those fields are purposefully undocumented so that Microsoft can change them as needed. Those fields are usually md5 hashes of a lot of information... it's basically there so that lots of information can be compared to be the same/different quickly via the hashcode so you know if the error is due to the same execution state as another.
It means you have an uncaught unhanded exception and it is crashing your application.
If it is working in debug mode you need to look to see what is different about the release version. Are all the libraries present? Do you have your app.config setup?
Check your event viewer under Windows Logs -> Application for more information.
If you setup an exception handler you will get much better information, such as a stack trace.
You need to produce a crashdump that can be analyzed after the fact. You will need to make some changes to the registry, and then you can analyze the dump file using Visual Studio. Hopefully, that will give you more clues such as specific function that is failing.
See this website for details:
http://blog.functionalfun.net/2013/05/how-to-debug-silent-crashes-in-net.html
You'll be setting up DebugDiag, a tool from Microsoft.
Let me know how things go or if you find some better tools.
Regards,
Dave
There is a nice feature in .net, Managed Debugger Assistants, to troubleshoot native and managed code interoperations MSDN article about using it here
Exceptions thrown by MDA can be configured in Visual Studio exceptions view window.
Trying to find a way to prove that my program is not running correctly because the version numbers of the dll's my interops are pointing to are different i.e. different GUIDs.
Works on my machine, not on "theirs" with the different dll's.
Can anyone recommend some debugging tools that let me watch the program as it starts up and see things like "looking for dll, not found, quitting"?
Is there logging tool available that would report these things to me?
If so I'm not aware of/using it.
You get an exception when a DLL isn't found. Or more commonly in your case, a COMException as soon as you try to use the interop library in your code. One drastic mistake you could make is catching such an exception. That's a very common mistake. But don't, undiagnosable failure is the result. There is rarely any point in letting your program continue running when an important chunk of code is just missing. Logging it isn't hard when you use AppDomain.UnhandledException.
This should at the very least provide you with decent diagnostics that help you to fix your code. You cannot get this started until you get good exception info. Pre-emptively fixing rather than waiting for the customer to get back to you with an exception trace usually requires you to recreate possible client configurations and testing your code. Highly advisable btw with 4 versions of IE in common use. You'll need a virtual machine so you can install the different OS and IE versions and test your code. Making the OS and IE version a system requirement is not unreasonable, ymmv.
You can try to do it yourself quick and dirty by enumerating all the assemblies loaded by your program via AppDomain.Current.GetAssemblies(). Also, check other questions about listing loaded assemblies, like this one
Read up on Assembly class in MSDN to see what information you can get about your assemblies.
I have a C# DLL that uses the XslCompiledTransform class for xml manipulations. I stole a C++/CLI wrapper for the C# DLL.
When using Delphi 5 to implement the C++/CLI wrapper, I receive a System Arithmetic error. Here is the Delphi 5 declaration:
procedure XsltMethod(XmlPath, XsltPath: PWideChar); cdecl; external 'ahma.dll';
The body of the C# public method creates a new XslCompiledTransform object and the exception pops up right when the newly created object runs its load method. For example:
XslCompiledTransform xslt = new XslCompiledTransform();
xslt.Load(XsltFile);
As mentioned earlier, the exception thrown from the .NET DLL is a System Arithmetic Exception. This only happens when called from a Delphi executable.
I guess I should mention calling the object's load method again works fine. So catching the exception and running the method for a second "pass" acts like a popup blocker. But for exceptions, of course.
Maybe you suffer from differences in the Floating-Point Control Register as stated here. Also see this QC report. You could try calling Set8087CW($133F); in your Delphi program. Be cautious of floating point problems in your Delphi code after that.
Random thoughts:
I think you should start by debugging your assembly from Visual Studio. Insert a messagebox or other wait statement in the Delphi code, then attach to process from Visual Studio. Tracing the C# might provide a couple of hints on what is going wrong. If you can't get it working, at least add logging of the incoming parameters.
In delphi, you don't need to escape backslashes.
Are you sure the E0434F4D is not some innocent first-chance exception? If you do not debug (or continue from the JIT debugger exception stop, which I'm not entirely sure is possible with Delphi 5), is the behaviour indeed faulty?
Could we please refer to "native Win32 assembly" as "DLL", like we used to call them for the past 20 years? :-)