MQ application team said their application got the MQRC 2008 return code when tring to get message from queue. I google with this return code but find nothing but MQRC_BUFFER_ERROR. And i don't undersand the description from MQ inforcenter as below:
Explanation
The Buffer parameter is not valid for one of the following reasons:
The parameter pointer is not valid. (It is not always possible to detect parameter pointers that are not valid; if not detected, unpredictable results occur.)
The parameter pointer points to storage that cannot be accessed for the entire length specified by BufferLength.
For calls where Buffer is an output parameter: the parameter pointer points to read-only storage.
Can you help tell me how to handle this error? Or What kind of perspective am i supposed to take in order to resolve this problem?
Thanks in advance
Related
According to the documentation, WTSFreeMemoryExA can be used to free a WTS_SESSION_INFO_1A structure by passing a WTS_TYPE_CLASS of WTSTypeSessionInfoLevel1. However, any attempt to do so fails with error code 87 (ERROR_INVALID_PARAMETER, "The parameter is incorrect").
How to get WTSFreeMemoryExA to work?
This appears to be a bug in Windows (at least in Windows 10 version 2004). Contrary to the documentation, the WTSFreeMemoryExA function does not accept WTSTypeSessionInfoLevel1, whereas WTSFreeMemoryExW does. This means that instead of using the WTSEnumerateSessionsExA function which returns WTS_SESSION_INFO_1A structures, you need to instead use the WTSEnumerateSessionsExW function which returns WTS_SESSION_INFO_1W.
This bug effectively makes WTSEnumerateSessionsExA unusable, unless you don't care about the memory leak caused by the inability to free its results. This bug appears to have been known about for some time. (Hopefully, some day, Microsoft will fix this.)
Some reports claim that even using WTSEnumerateSessionsExW and WTSFreeMemoryExW appears to leak memory, which implies that WTSEnumerateSessions combined with WTSQuerySessionInformation may be the better approach. However, I myself have been unable to reproduce that issue. I suspect it was a real issue at one point, but has been fixed by Microsoft in more recent Windows versions.
thank you for raising this question.
We checked the relevant source code and found the source code related to WTSFreeMemoryA. It accepts the first parameter WTSTypeClass as WTSTypeProcessInfoLevel0 or WTSTypeProcessInfoLevel1, but it doesn’t accept the value WTSTypeSessionInfoLevel1 and therefore return the ERROR_INVALID_PARAMETER error on this call.
This is different from the description in the document, we will submit this issue. And you can try to use WTSFreeMemoryW to avoid this issue.
I am trying to understand the Go 1.13 error handling from https://pkg.go.dev/github.com/pkg/errors?tab=doc#pkg-overview but could not get the meaning of the following description:
which when applied recursively up the call stack results in error reports without context or debugging information
Could someone please provide an example in corresponding to sentence above.
What is the advantage of error in Go 1.13 in comparing to old style error handling?
Reading the next section on the page could potentially enlighten you.
The "err" being returned recursively, is the error being propagated to the caller, ultimately reaching the top level caller (main for instance), this is what this means.
Now if the cause or detail of the error is not specified, it is going to be very hard to know how to fix it. Providing context, ensures that the emitter of the error can be easily identified.
I'm new to reverse-engineering all in all and been having real difficulty to find exactly what makes a message box appears in the application which I don't have the source code for.
I tried using the very slow search for text to see if it would find the "Error when trying to download (...)". But looks like the message text is received from the wire and, therefore, is not a const string inside the binary.
I also have absolutely no clue of where the function is because I can't "instantly break" when the message pops up, so I would like to know if is there a way to create a watch for value kind of thing?
The idea is to make IDA be prepared to break if any address has the int32 value 65000 (decimal) assigned to it.
If you want to "watch for the value 'Error when trying to download (...)'" - then you'd probably find out that it is very complicated, resource heavy, although possible. You'd have to "trace" into every opcode that the processor executes and check where ever you need (e.g - the stack) for that value (or a pointer to it), which can be done with PIN Tools. This tool allows you to efficiently execute any assembly code you wish between each opcode, function call or "block" (as represented in IDA), by manipulating surrounding opcodes so they won't get affected. It's a really interesting thing to try.
However, what you probably want to do is break on MessageBoxW or MessageBoxA. Simply navigate there (press G and write MessageBoxW and place a breakpoint). This will break when the application will call MessageBoxW, and you can then inspect the stack to see where it was called from.
Is parameter validation using error return codes considered good practice ? I mean where should somebody use errors vs panics (are there any guidelines?).
For instance:
Is checking for non-nil + returning an error if it is nil a good
practice ?
Or checking for correct integer ranges etc.
I imagine that using errors that often would make Go feel very C-ish and would look pretty bad. Are panics a good alternative in those situations ?
Or should a Gopher use the Python/Ruby/JS-approach "just let it fail" ?
I'm a bit confused because panics are for real "errors" in my understanding. But using errors all the time is just bad.
And even if I would return error code: What could I do if somebody passes wrong parameter to my function but ignores the errors codes ? -> Nothing! So honestly I would say panics are nice for those situations but in a language where error codes are used over panics this is not very clear.
"Escaping" panics1 in Go (I mean, those which might be produced by the functions comprising the public API of your package) are to deal with errors programmers do. So, if your function gets a pointer to an object, and that can't be nil (say, to indicate that the value is missing) just go on and dereference the pointer to make the runtime panic itself if it happens to be nil. If a function expects an integer that must be in a certain range, panic if it's not in that range — because in a correct program all values which might be passed to your function are in that range, and if they don't then either the programmer failed to obey the API or they did not sanitize the value acquired from the outside which, again, is not your fault.
On the other hand, problems like failure to open a file or pefrorm some other action your function is supposed to perform when called correctly should not cause panics and the function should return an appropriate error instead.
Note that the recommendation for explicit checking for null parameters in the functions of public APIs in .NET and Java code has different goal of making such kinds of errors sort-of more readable. But since 99% of .NET and Java code just lets all the exceptions propagate to the top level (and then be displayed or may be logged) it's just replacing one (generated by runtime) exception with another. It might make errors more obvious—the execution fails in the API function, not somewhere deeper down the call stack—but adds unnecessary cruft to these API functions. So yes, this is opinionated but my subjective opinion is: to let it just crash is OK in Go—you'll get a descriptive stack trace.
TL;DR
With regard to processing of run-time problems,
panics are for programming errors;
returning errors is for problems with carrying out the intended tasks of functions.
1 Another legitimate use for panics is quick "cold-path" returning from deep recursive processing/computation; in this case panic should be caught and processed by your package, and the corresponding public API functions should return errors. See this and this for more info.
The answer to this is subjective. Here are my thoughts:
Regarding panic, I like this quote from Go By Example (ref)
A panic typically means something went unexpectedly wrong. Mostly we use it to fail fast on errors that shouldn’t occur during normal operation, or that we aren’t prepared to handle gracefully.
In the description of your use case, I would argue that you should raise an errors and handle the errors. I would further argue that it is good practice to check the error status when one is provided by the function you are using and that the user should check if one is provided in the documentation.
Panics I would use to stop the execution if I run across an error that is returned from the function you are writing that I check and don't have a way to recover from.
I am retrieving system failure information from the event logs for diagnosis of system crash and displaying a list of possible issues.
In a generic BSOD, what do the four hex values in brackets signify. Is there anyway they can be used for further diagnosis of the problem, beyond the main error code? i.e 0x000000A. If yes, how?
The first number is a bug check code.
The following numbers will be whatever the driver passed to KeBugCheckEx, so they're only really useful if you have the driver source code.