There are three different return/error/status code types I get while calling native function using P/Invoke.
The first one is the usual error code I get by calling Marshal.GetLastWin32Error static method.
The second one is HRESULT I get while calling some COM-helper functions.
And the third one is NTSTATUS I get while calling native apis from ntdll.dll library. I have a loging function that logs the return/error/status code as a hexidecimal number, then when an error is found in the logs I need to use google to find out what the actual error is.
So I'd like to ask if there is a good way to convert these return/error/status codes to string (preferably in English) to log the return/error/status string description instead of a number?
Is there a way to convert between LastError/HRESULT/NTSTATUS codes, so that the semantics of the error message would stay the same?
You can use errorlook tools for this purpose. This link is kind of old, I learned this in my old VC++ days and you can use it as a start point to find modern tools.
As for the logging I would suggest you keep the original error codes. Meaningful error messages are easier to read, but the original error codes are accurate keywords to the search engines.
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
I am logging error messages and .NET exceptions of my application in a database and display them on a GUI. The GUI displays error messages in the language of the locale of the user running the application. In order to achieve this I log resource names of error messages only, and turn them into meaningful messages using resource files.
I, however, cannot wrap my head around how to achieve the same for .NET standard exception messages. I can only log the message string, but then the language is already 'baked in' so I can only display the exception in that single language.
Is there a way to get the resource name of the .NET exception + all parameters that are inserted into the message string, so that I can log these?
There is no such thing as resource name for an exception, but there is the HResult property of the Exception class. The standard .NET framework exceptions have valid and unique HResult numbers which you can map then to your own resource identifier that you can translate then.
Furthermore there is the Exception.Data property as well, which may contain additional information about the exception.
Or, you can parse the exception messages manually, using regex or such and then map to your resource id, but this is too much effort I think.
I had this problem too and did a fair amount of research on it. Based on everything I could tell there was not a way to localize the exception itself because what you're seeing is not localized strings, it is actual code. The code is only written in one language (english) and can only be displayed as such.
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.
In languages that support exception objects (Java, C#), when is it appropriate to use error codes? Is the use of error codes ever appropriate in typical enterprise applications?
Many well-known software systems employ error codes (and a corresponding error code reference). Some examples include operating systems (Windows), databases (Oracle, DB2), and middle-ware products (WebLogic, WebSphere). What benefits do error codes provide? What are the disadvantages to using error codes?
WITHIN a program one should always use exceptions instead of error codes. However, exceptions can't propagate beyond a program. Any time the error must leave the program you are left with error messages or error codes.
For simple things that will always be human-operated error messages without codes are fine. You can say "File not found" without giving it an error code. However, if it might be another computer on the other end then you should give error codes in addition. You don't want to break the other system when you change it to "File <x> not found".
I don't think I've ever used error codes in .Net except in one situation - when I was creating a console application that I knew was going to be called from another app. This other app had to know when the console app failed, and what went wrong. So, one example of when it would be appropriate would be when you know your program will be called by other programs, and you want a structured way for them to understand errors.
That said, I was a newbie to .NET at the time, and have never used error codes since.
As a side note, as a Windows guy, it's nice to be able to plop in an error code and come up with a KB article, so an error code combined with good documentation and the ability to find it = nice feelings from your users.
Very common for web service interfaces. It's very easy and standard to return a code with a description.
I agree that for most of the scenarios is old school
I'd say the biggest disadvantages it's the quality of code. You have to add more complex logic to manage error codes while exceptions are bubbled without having to use method parameters or return values.
You also have to add an "IF" to check if the returned code is SUCCESS or not, while exceptions goes directly to the error handling block.
I'm a newbie to stack overflow but...
I believe that error codes tend to be used or useful for dealing with erroneous situations that require an end-user of sorts to get involved to rectify a situation. If your code is to be maintained by another developer then exceptions is the way to go. However, in a situation where there is a problem:
in the environment that your application is running
with communication between your app and some other entity (web server, database, socket, etc)
that a device or device driver indicates (hardware failure maybe?)
then error codes may make sense. For example, if your app attempted to log into a database on behalf of your end-user, but the DB was unreachable for authentication (DB is off-line, cable is unplugged) then an error code/description combo might help the end-user rectify the problem.
Again at the developer/engineer level who will be able to touch the source code (traditional debugging and testing techniques) and modify it, use exceptions.
Hope this helps...
--jqpdev
I frequently use error codes when an error needs to be conveyed to the user, since they can be internationalized. For example, in a compiler, if there are errors in user code, errors can be signaled in the compiler backend, while the frontend can localize them into culture/language-specific strings for user consumption. Enums may be better for this purpose than raw integers, however.
I've also used them in creating an "error reporting" framework for the app. When exceptions were thrown, they were thrown with an error code, which, when the exception bubbled up, was sent (with a log) to the central server. The code helped organize the database so we could inspect logs related to a specific error.
Finally, as mentioned in a couple other answers, error codes are easy and language-agnostic to google (think Windows error codes/MS KB articles), so an error code with a description of what went wrong may be better for end-users of a technical product.
The idea of error codes is useful, but IMO they belong as exception members or as parameters to an IErrorReporter interface or something more ofthen than as method return values.
Error codes are old-school. They are of little to no value at all.
The only possible value to an error code is that it can identify a very specific circumstance. You could have a code for each point in the code base that can throw an exception. This would allow you to narrow down very precisely what the problem must be.
But nobody cares about that level of detail. Who wants to maintain such a mess. It would leave you with codes that meant something like "condition A and B but not C due to state S". It's more effort than it's worth to try to work out exactly what that means. A stack trace will be more valuable in telling you where in the program the problem occurred.
I learned to program computers before exceptions were a widespread technique. I'm so glad we got exceptions instead!
C#, and probably Java too, supports a better exception handling control flow, the finally keyword, which makes things a little nicer than using error codes. An exception object can contain any level of detail, certainly much more than an error code. So the exception object is way more practical, but you might run into an uncommon case where an error code would be more appropriate.
FWIW, C++ also supports exception objects. I don't think that C++ supports a finally keyword (though the newer C++ whatevers just might), but in C++ you also have to avoid things like returning inside a catch handler.
Error codes were designed in an age where the only way for a function to tell the caller that something went wrong was to assign a special meaning to one or more values of those which can be returned, and very frequently only a native integer or so was available for returning that special value.
For instance, in C the "get character" routine returns the next character value in ASCII, but returns a negative value if for some reason something went wrong. You are then responsible for returning to YOUR caller in a way so this error situation can be handled, and that must return etc.
The Exception mechanism is an elegant way to handle this "this is an emergency, we must return from code until something can deal with the problem". Error codes are inferior to this.
I've written many web services that are consumed by other (remote) applications. When things go badly with a request, customers more or less insist on getting a code, so that they don't have to do some horrific string comparison to find out what went wrong.
Take HTTP result codes as a fine example of this sort of behavior. "200" means happy, "300" could go either way, "400" or "500" means start freaking out.
Error codes are for if you want to send them to the user. If not, use an exception.
Sometimes you don't want to give too much information to the user when an error occurs. For example, a user is not able to sign a new contract. The error message only states something generic like "Cannot sign a new contract".
This adds difficulty to support cases where the user thinks this is not correct. If you have an error code, for example a number or an acronym, it could be part of the error message. The user wouldn't know what it means but the support staff could look it up and could then check if that specific reason for declining the new contract is indeed an error or not.