What error codes can a failed call to AllocConsole generate? On the MSDN website it says If the function fails, the return value is zero. To get extended error information, call GetLastError. But I see no place saying what kinds of errors it can generate.
In most system calls, there is a rather long list of "possible failure scenarios", and that means that you get a large number of possible error codes. For example, some resource in the OS may be full (I expect there is a list of consoles in the OS somewhere, and if that list is full and/or can't be grown, there is some error for that). The Console also needs to have memory as a buffer for the text content, as well as a graphical output buffer (to avoid having to draw every character every time the screen is refreshed) - both of these lead to at least two distinct errors (out of memory, out of graphics memory, and possibly "no way to create a handle for the graphics resource").
A different category of possible errors are permission based ones - maybe your process (based on the user being logged in) doesn't have enough permissions to create a console.
I'm pretty sure the list of actually possible errors is much greater than that.
In summary, don't expect that the errors you can get from a function is limited - if you are interested in a particular set of error codes, then check for those, and do something sane if it isn't one of those. Don't expect that you can't get any other error code.
Related
Example: Here's the debug log for CreateGraphicsPipelineState, it tells me what went wrong:
D3D12 ERROR: ID3D12Device::CreateGraphicsPipelineState: Root Signature doesn't match Vertex Shader: Shader CBV descriptor range (RegisterSpace=0, NumDescriptors=1, BaseShaderRegister=0) is not fully bound in root signature
However, a call to windows FormatMessage(MESSAGE_FROM_SYSTEM...) will return this for the exact same error:
The parameter is incorrect.
The first is obviously far more useful...
We used to have dxerr.lib, and we have source for dxerr.cpp in DXUT. But this doesn't cover DX12. I can't see any way for a shader-tool to retrieve the error and present it to the user from the API.
This can be done with the ID3D12InfoQueue interface, as documented here:
https://learn.microsoft.com/en-us/windows/win32/api/d3d12sdklayers/nn-d3d12sdklayers-id3d12infoqueue
As far as I can tell it's currently not possible to set a callback, which means that you'll need to explicitly query for feedback.
There are two different sources of error/status information involved here. The error code you have returned from the API call is E_INVALIDARG and you obtained a good string for it. This is the status code from the API.
The descriptive message you see in debug output is emitted by Direct3D 12 debug layer, which you loaded during API initialization. It is, generally speaking, an optional component and might be not available in the system while the API itself is available.
To intercept debug output programmatically you can either
utilize this trick: Capture OutputDebugString output
or, attach as a debugger to your application and process debug output event recording the contents
I am currently learning C++ in connection with WinAPI. I am struggling to come up with meaningful error handling strategy for WinAPI functions.
PROBLEM:
Most of WinAPI functions can return 0 in case of error, but in many cases I don't see any information on MSDN as to what could cause such error and how to address / resolve it. Taking GetCursorPos as an example:
Returns nonzero if successful or zero otherwise. To get extended error information, call GetLastError.
(...)
The input desktop must be the current desktop when you call GetCursorPos. Call OpenInputDesktop to determine whether the current desktop is the input desktop. If it is not, call SetThreadDesktop with the HDESK returned by OpenInputDesktop to switch to that desktop.
If I follow the route of GetLastError I am interested in what errors could be returned by that specific function so that I can inspect what can be done about them. But error codes are organized on this MSDN page into 10 groups based on just error number and without any specification of what errors are listed in which group.
When I tried to discover how would OpenInputDesktop help me make my code more bulletproof I discovered that again:
If the function fails, the return value is NULL. To get extended error information, call GetLastError.
To sum it up: almost every function in WinAPI can return value determining occurrence of error and I can get information on the error when it happens using GetLastError function. But no information whatsoever on what kinds of errors I can expect and what steps to make to resolve them.
The examples are many, GetWindowRect is also widely used and MSDN delivers the very same limited information as for GetCursorPos.
QUESTION:
Please are there any standards on how to approach WinAPI function error return values that would retain error handling from becoming just showing a message box and exiting the application? Thank you!
As far as knowing ahead of time what possible error codes can be returned by a particular function, I'm afraid that Microsoft decided long time ago that maintaining such documentation for all functions would be too cumbersome and costly, as an API function may call any number of other API functions, which in turn may call others and so on. Sometimes you get lucky and the MSDN doc calls out error codes specific to that function, as is the case with ReadFile but this is not the case with all functions as you have noticed.
That being said, the standard way of dealing with the error codes returned by GetLastError() is to format them with FormatMessage.
If you passed LANG_USER_DEFAULT for lang ID, this will return the sometimes helpful, sometimes not so helpful error message formatted in the user's chosen locale from the error code. You can show this message to the user. If you wanted to format it in your own language for logging purposes, assuming it's English, you would pass MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US) for lang ID.
And this is the best you can do if the error codes are not documented and you haven't come across them in testing: log them and get the log with other debug info attached to the issue report.
I have a POS application written in Delphi, which has been working fine until now.
I had to add a webservice client to have some documents validated by the goverment, and even though I had never worked with WebServices/Encryption before, I managed to do it (thanks to the internet really).
When I run the program and create one of those documents, it is perfectly validated (the webservice is accessed, a SOAP envelope with some data is sent, and the response from the server is received without any problems).
The problem is, if I create another document, when I try to validate it I get an "Access Violation at 0x07e7bcb5: read of address 0x00000012".
My validation routine is a function inside a DLL. Before it was inside the DLL, I had all the code inside the main project, but it crashed my program: if I would validate a document, the response would come, but I would get an Access Violation when I terminated the program or if I tried to validate another.
I also tried loading the DLL dinamically, so the validation process would "start from scratch" at each run, but it was useless.
I've been trying to debug this, but I just can't get it. Running step by step, it fails in some line, I comment it out, and the next run it fails in a completely different place.
I tried also EurekaLog, but I couldn't figure out what to do with the info it gave me (I had never worked with it).
Any direction I should be taking?
Thank you very much!
Nuno Picado
EDIT:
I should probably mention what I'm using to access the webservice:
- THTTPReqResp and WinINet for the communication
- IXMLDocument to create the SOAP Envelope
- LibEay32 to encript some data required by the webservice
- TZDB to get the universal time from a web based server
- Capicom 2.0 to load a certificate required for the communication
I use EurekaLog at work, to debug errors that happen at client installations. Here's what you do with the information EurekaLog gives you:
Fairly high up in the report should be one stack trace for every thread in the program. The one on top should be the one in which the error occurred. That's almost always the most important thing in the error log: it tells you exactly what was going on when the exception was raised.
Find the place in your code that corresponds to the top of the stack trace. An access violation means that somewhere, your code tried to access (read, in this case) memory that's not mapped to your program's address space. A bunch of leading 0s means that you're trying to read at an offset from a null pointer. This almost always means one of three things: You're trying to read the value of an object whose value is nil, you're trying to call a virtual method on an object whose value is nil, or you're trying to read an element of a string or dynamic array whose length is 0 (and this is currently represented by a null pointer).
Now that you know what you're looking for, have a look at the code and see if there's any way that that could be happening based on the information you have available.
I am developing an application using Django that works similar to a project manager. For this reason, the system should be capable of storing information about everything. When I say everything I refer to the actions the users do, the errors that occurred while doing an action, etc.
I have a class Log and one of its attributes is called action_type, this attribute specifies what kind of action just happened. I am supposed to have 5 kinds of types:
INFO: this log stores the information related to user's actions such as creating a project, create other users, etc.
DEBUG: should store comments made by the developers that will allow them to detect errors.
ERROR: shows errors that occurred in the system but they don't affect the system's functionality.
WARNING: it's for potentially damaging actions.
FATAL: unexpected errors, exceptions and security breaches.
I can only come up with logical logs for INFO.
Could you tell me some reasonable logs that I should include in this and the other categories?
The answer will depend greatly on exactly what your application does, but my basic approach is this:
Each time you get ready to log an event, just think about the event and it will be clear where it belongs. Did it kill your application? It's fatal. Did it prevent something from working correctly? It's an error. Could it prevent something from working, and did we just get lucky this time? It's a warning. Does anyone care? Info. Otherwise, if you still need to log it, it must be for debugging purposes.
In your particular context, it sounds like you might only be trying to log user actions. If that is the case, the only actions that could be fatal would be ones for which you don't provide an undo option (or, I suppose, if the user is able to order a piano bench and a length of strong rope through your application). I also couldn't really imagine any debug-level logs coming from user actions. Because of this, I assume you will be logging code level events in addition to user actions.
FATAL: This should only appear in the logs when your application actually crashes, and possibly alongside 500 responses. You might generate these within your wsgi application in a catch-all, only when the process would otherwise have died.
ERROR: Likely tied to http error responses. This is typically for errors caused by something outside your application. Things that happen in your code are probably expected and <= warning level, or unexpected and fatal. Errors might be a 404 from the user making a typo in a url, validation errors on form submission, or authentication errors. From the other direction, errors might be returned from remote web services that you contact or IO errors from the os.
WARNING: For things that don't break anything, but that might bite you if you keep it up. Examples are using deprecated apis and anywhere something only worked because of the default (time zone, character encoding, etc). Maybe certain input values result in warnings, too, like setting a due date in the past.
INFO: General, healthy operation. Someone created a database row (a new project or a task?), created an account, logged in or out, a socket was successfully opened, etc.
DEBUG: Just what it says. Output that you will usually turn off once the code is working correctly. Method entry/exit, object instantiation, field values at various points in the code, counters. Whatever you need to figure out why your program is crashing right now, as you work on it.
In a program I'm developing I need to gather information about runtime errors. Currently, I am able to gather all the information I need, including the message via FormatMessage, but the identifier of the error (for example, ERROR_SUCCESS). I know that when the application is compiled these identifiers are not actually present in the binaries.
Is there a function in the Windows API which can retrieve these identifiers or do I need to store them with my application?
ERROR_SUCCESS itself is just a constant. I haven't found a way to go from number -> constant identifier.
You could scan WinError.h with Clang and create some kind of table for your application.
Here is a nice example of how you can get the ErrorCode and how to translate it to a more readable message on MSDN.
No need to copy that over, its quite plain:
Retrieving the last error code and message