I update my computer to Windows10.
It cause an exception in OutputDebugString callstack i guess.
When i called OutputDebugString, the callstack was shown like this.
ntdll.dll!_WerpWaitForCrashReporting#16()
ntdll.dll!_RtlReportExceptionHelper#16()
ntdll.dll!_RtlReportException#12()
ntdll.dll!_RtlpReportInvalidExceptionChain#8()
ntdll.dll!RtlDispatchException()
ntdll.dll!_KiUserExceptionDispatcher#8()
KernelBase.dll!_RaiseException#16()
KernelBase.dll!OutputDebugStringW()
It looks like windows error report process.
Why dose this happen?
Is OutputDebugString deprecated in Windows10?
Thanks.
Why does this happen?
There is an error in your code somewhere. Perhaps a heap corruption, or an invalid argument passed to the function. For. Instance it may be that the string is not null terminated, or that the memory you passed has already been freed.
If I had to bet, I would expect that this final explanation is the most likely.
Is OutputDebugString deprecated in Windows10?
No. Much as you might be inclined to think the problem is related to the OS upgrade, it is an issue with your code. The upgrade has just happened to highlight the problem with your code, a problem that has always existed but only now happens to manifest.
OutputDebugString works by generating an exception. The debugger catches it as a debug event ("1st chance"), then extracts the string argument and displays it.
The important part in the stack you show is _RtlpReportInvalidExceptionChain. What this means is that somehow your try/catch chain was corrupted. Perhaps a mismatch in exception handling model (/EHsc) or otherwise.
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.
For some time I observe the following behaviour in Qt Creator. Each time I run an application, I get similar messages in the console:
WTContextManager() this:e9ed0340
WTRoundArray() this:e9ed0bc0
...
~WTRoundArray() this:e9ed0bc0
~WTContextManager() this:e9ed0340
This is not a warning nor an error, but just a text, and it happens regardless of the code I have written.
What are the WTContextManager and WTRoundArray classes and why they cause such output?
This is indeed a rare behavior. It is caused by the HUION Drawing Tablet drivers, as described here.
Removing the drivers removes the text.
However, since it does not influence the applications in a bad way, I do not think it should be of any consideration.
Currently, I see a recurring error:
2013-04-18 02:35:51.583 aaah[1713:1110f] *** Terminating app due to uncaught exception 'NSGenericException', reason: '*** Collection <__NSArrayM: 0x1fc00dc0> was mutated while being enumerated.'
In the failing background queue (I see my queues state upon the moment of a crash by pressing Command + 5) I see:
0 _pthread_kill
1 pthread_kill
And I see assembly output which I completely don't understand.
I know how to resolve this kind of array enumeration errors - I just can't understand where/how I should seek for the piece of code causing my app to crash.
I have much multi-threaded code using AFNetworking and Core Data, so I can't just remember where the crucial section might be.
Also, this error occurs not always, but from time to time, so it is difficult just to use "isolation approach", isolating smaller and smaller pieces of code, to finally identify the buggy piece of code.
So the question is:
How can I extract some more useful information from this output, or Xcode can provide me with some more verbosity level, so I could know how to resolve this annoying piece of code.
Have you tried setting an exception breakpoint? Sometimes the debugger struggles with exception handling inside blocks but it might help.
In the breakpoints navigator (one of the tabs on the left side of the window) click the plus button at the bottom of the window and select add an exception breakpoint. Then hit done.
Now when you crash, the debugger should hopefully put you right before the instant the exception was raised.
See http://developer.apple.com/library/mac/#recipes/xcode_help-breakpoint_navigator/articles/adding_an_exception_breakpoint.html for more info.
Edit:
Based on the feedback provided in the comments, here's some more analysis:
The exception your application is raising means that you attempted to change a collection type (in this case, an NSMutableOrderedSet) inside of an enumeration block (in your case, most likely a for-loop). It looks like you're trying to remove objects in a set that you are looping over: [NSMutableOrderedSet removeObjectsInRange:inOrderedSet:]
To resolve this you should store the ranges you wish to remove and then do the actual removing once you're no longer iterating over the set. It's still going to be difficult since, as I understand it, you're not breaking inside of Objective-C code. You should look at the running threads in the panel on the left and look at what method they're currently in. That might give you a hint as to where your code is wrong.
I have a process that handles exceptions great. It calls:
_set_se_translator(exception_trans_func);
SetUnhandledExceptionFilter(UnhandledExceptionFilterHandler);
_set_purecall_handler(purecallHandler);
set_terminate(terminateHandler);
set_unexpected(unexpectedHandler);
_set_invalid_parameter_handler(InvalidParameterHandler);
atexit(exitHandler); //ignored during an expected exit
_onexit(onexitHandler); //ignored during an expected exit
Anytime an exception happens, one of the handlers is called which creates a crash dump for me. Life is good.
Except at one customer site. When they shutdown the process, there is an exception that isn't routed through these calls for some reason and they get the error:
The instruction at "0x101ba9df" referenced memory at "0x00000004". The memory could not be "read". Click OK to terminate...."
The memory reference of x000000004 looks like it's probably a null pointer. And looking at that address appears to be a global STL object's destructor (probably in the CRT's initterm call where globals are cleaned up).
Right now I'm kind of stuck though since I can't get a diagnostic dump and call stack and see exactly what is going on. So....
Why isn't the exception being routed through the above handlers, and instead being shown to the user?
Is there any way to hide that dialog (since no harm is being done at that point)?
And is there a way to track down the root error?
Thanks for any ideas.
What operating system are they running?
I assume you're setting the error mode using something like
::SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);
to make sure that windows isn't jumping in with its own error handling?
This sounds like the CRT has put an SEH try/catch block (can't write it properly, Markdown kicks in) around some piece of code, and is catching the exception to display the message, so you never end up calling the unhandled exception code path. You might have to do some CRT hacking to figure out what's happening.
It could be that STL code is being executed during the destruction of global variables at program shutdown time and perhaps (depending on the version of STL that you're using) some global variables that it requires have already been destroyed.
I've seen this with VS2008's STL. There are some STL lock objects that are created via a file level static during start up.
Are you using STL in your error handler functions? It could be that one of these is going off late in program shutdown and causing the problem.
I want to access the call stack at runtime in a Native C++ application. I am not using the IDE. How do I display the call stack?
Update: I have a function which is called from many points all over the application. It crashes on rare occasions. I was looking for a way to get name of the caller and log it.
Have a look at StackWalk64.
If you're used to doing this on .NET, then you're in for a nasty surprise.
I believe that this page has the answer you are looking for. You said Visual C so I assume you mean windows.
You should consider setting your unhandled exception filter and writing a minidump file from within it. It is not all that complicated and is well documented.
Just stick to the minimum of things you do once in your unhandled exception filter (read what can all go wrong if you get creative).
But to be on the safe side (your unhandled exception filter might get inadvertently overwritten), you could put your code inside __try/__except block and write the minidump from within the filter function (note, you cannot have objects that require automatic unwinding in a function with __try/__except block, if you do have them, consider putting them into a separate function):
long __stdcall myfilter(EXCEPTION_POINTERS *pexcept_info)
{
mycreateminidump(pexcept_info);
return EXCEPTION_EXECUTE_HANDLER;
}
void myfunc()
{
__try{
//your logic here
} __except(myfilter(GetExceptionInformation())) {
// exception handled
}
}
You can then inspect the dump file with a debugger of your choice. Both Visual Studio and debuggers from Windows Debugging Tools package can handle minidumps.
If you want to get a callstack of the crash, what you really want to do is post mortem debugging. If you want to check a callstack of application while it is running, this is one of many functions SysInternals Process Explorer can offer.
If you're not actively debugging, you can "crash" the app to produce a minidump (this can be done non-invasively and lets the app continue running). IIRC DrWatson will let you do this, if not userdump from MS support will.
You can then load the dump into windbg and see the callstack + variables etc there. You will need your app's symbols to make sense of the trace.
If you're looking for a simpler run-time code style traces, I recommend a simple class that you instantiate on every method, the constructor writes the method name using OutputDebugString. Use WinDebug to view the trace as the program runs. (put some form of control in your class, even if its just a global variable or registry value, or global Atom so you can turn the tracing on or off at will).
It crashes on rare occasions. I was looking for a way to get name of the caller and log it.
What do you mean by it crashes? Access Violation? Divide by zero? what exactly? Does it interact with kernel mode components?
Turn on appverifier. that should eliminate a lot of things.
create this:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\FileName.exe
under that key, create a new string
name : debugger
value: c:\pathtowindbg\windbg.exe -gG -xe av
If you're running 32bit code with WOW, you need to do this under the wow3264node.