I've assembled my new PC yesterday, and I've decided to give Windows 8 a try. However, today, during the debugging of moderate Qt application, debugger yielded "Invalid Binding Handle" error message on a pretty simple line (it was line that is auto-generated by Qt's moc.exe:
// QWebView *view (...)
view->setUrl(QUrl(QString::fromUtf8("about:blank")));
// Failing in setUrl call, not in QUrl constructor, or in fromUtf8 function.
However, running this application without debugger works just fine, both in Release and Debug versions.
I've got some clues on the internet to enable Terminal Services, but it seems that there is no such service in Windows 8.
Does anybody have any clue what should I check?
Edit
Moving the widget into other application yielded no error, so apparently, widget (which is pretty small - just QWebView and QProgressBar) is fine. But, when I show this widget in my main function:
QApplication app(argc, argv);
MyWidget w;
w.show();
return app.exec();
it is still failing with the same error. Examining call stack (which is not very helpful when error appear) and stepping into function calls, I've tracked error down to retval = HeapFree(_crtheap, 0, pBlock); in function _free_base, in file free.c And it seems that function is called from dbgdel.cpp, function _free_dbg( pUserData, pHead->nBlockUse ); and it is called from unlock() function.
Attaching the debugger to already active process is still yielding the same error.
I am linking a lot of 3rd party libraries here, so I will try without them, as I'm run out of ideas...
Edit 2:
If I pass this exception to the program, it seems to be running fine.
Edit 3
Commenting setUrl line raises the same exception somewhere in QWebKit, where strdup function is called...
Well, this was easy, but it took me two months to solve (while ignoring the error in the meantime).
This was not an unhandled exception - this was handled exception, and stepping into assembly code and watching the stack frame told me that this exception was handled.
Then I remembered that I've set debugger to break when all C++ and Win32 exceptions are raised. Resetting the debugger settings removed the issue.
Related
Using UI Automation for some Windows I get the following exceptions on a IUIAutomationElement::FindAll() call using VS2017. First question, what is a wil:ResultException and what does it mean it rethrow at memory address 0? I check the FindAll() result and doesn't seem to have FAILED(hr) because it outputs a debug message if it did and it's not.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: wil::ResultException at memory location 0x000000550AF2BDC0.
Exception thrown at 0x00007FF897AC3E49 in app.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
I don't know if it is related or not. I turned on the fairly new "Use Text cursor indicator" as users are telling us our app can crash when it is on. After doing some testing, I was closing the app and got an access violation deep in UIAutomation.dll. The system was just exiting the process. I was trying to duplicate the crash and though I didn't crash, I just saw this same message and the reply to this post that mentioned UIAutomation. The "fairly" new setting is new to me because our IT just allowed the version update that has the setting on our boxes.
The crash occurred while doing a PeekMessage during the exit of the process. We had a static c++ object that was being deleted and during that call, it called the API. I rearranged the code to make the call that used PeekMessage so it happened before the process exited. That avoided that crash. However, we are MFC based and in a debug build, if any code does an ASSERT during shutdown, MFC's assert code does a PeekMessage to remove WM_QUIT before showing the assert message box. So, we can still crash there randomly in our debug builds.
When running with the Text Cursor Indicator on, I see a lot of these "wil" exceptions in the debug output window (release or debug builds). Many seem to occur when a window that has the indicator drawn over it closes. Example - standard file open dialog. I open it, click the path edit box and when I close the dialog, I get some of those exceptions. Turning off the indicator setting avoids all of that and the crashes.
I'm using cocoss2d with c++ on windows 10 and I'm trying to play background music. It works the first time I debug the game but on the second time I hit run it throws these exceptions
Exception thrown at 0x765F3E28 (KernelBase.dll) in MiniGolf.exe: 0x000006BA: The RPC server is unavailable.
Exception thrown at 0x765F3E28 (KernelBase.dll) in MiniGolf.exe: 0x0000000E: Not enough storage is available to complete this operation.
Assert failed: getFileSize should be override by platform FileUtils
Assertion failed!
I simply use this line to start the music.
CocosDenshion::SimpleAudioEngine::getInstance()->playBackgroundMusic("level_music1.wav",true);
I'm not sure what's going on can anyone share a light with me ?
cocos2d-x 3.9
CCWinRTUtils.cpp
line 336 added
if (ret[0] == '/') {
ret = ret.substr(1, ret.length() - 1);
}
Got it! It's not that good fix, but still.
File: CCWinRTUtils.cpp
Method: createMappedCacheFile
I have commented if/else construction and call FileUtils::getInstance()->removeFile(prevFile) all the time.
Now it works fine on both Windows10 and Windows Phone 8.1.
As I understand now the caching works only for current session. The previous solution (caching by hashtag) was for caching sounds loaded from the Internet and not needed for local files.
I have an application that works fine under visual studio.
However, when I run it stand-alone, a certain operation which throws an exception isn't handled. (The exception is expected, but it's correctly handled under VS.)
I added a line to my machine.config to enable JIT debugging, to try and locate the problem, but I then could not recreate the bug (the exception was handled correctly). Deleting the line causes the bug to come back.
How should I start looking for the cause?
The relevant parts (I believe) of my code (edited to remove extraneous detail) are at http://pastebin.com/i2zLCTn5.
Some suggestions that may affect how your code is behaving in the different environment of Visual Studio:
Stop Visual Studio turning off the JIT Optimizer when you run your program under Visual Studio.There's an option called "Suppress JIT optimization on module load"...you want to try changing that to be NOT ticked.
For more details on what the option does see here:
http://msdn.microsoft.com/en-us/library/ms241594.aspx
Turn off the "hosting process" ...http://msdn.microsoft.com/en-us/library/ms185330(v=vs.80).aspx
Run the Program, then "Attach to Process" (it then won't be in a hosting process, and the modules will have been loaded and JIT optimized).
In the Exceptions dialog tick the "Thrown" check box of the Exception that is being eated/handled....so that you can track down who is handling it and why. You will need to install the NET Framework Sourcecode if the Exception is being handled there so that you can see the details.
You could have a try at running it under WinDBG instead (it may behave differently as you then won't be running under a hosting process i.e. .vshost)....make sure you have the extension DLL PSSCOR4 (if using .NET 4) so that you can make sense of things.
So, I discovered - or rather, a friend explained - the cause of this problem:
You cannot catch exceptions across threads when JIT debugging is disabled, even if execution appears to flow correctly.
The exception was being thrown in a Form.Closing event handler:
form.Closing += new delegate
{
switch(form.DialogResult)
{
case DialogResult.OK:
// do stuff;
break;
case DialogResult.Cancel:
throw new AbortOperationException();
}
}
// ...
try
{
mainForm.Invoke(new Function<Form, DialogResult>(form.ShowDialog), mainWindow);
}
catch (AbortOperationException)
{
// handle abort
}
The solution was to refactor slightly to eliminate the throw:
form.Closing += new delegate
{
if (form.DialogResult == DialogResult.OK)
{
// do stuff
}
}
// ...
var result = (DialogResult)mainForm.Invoke(new Function<Form, DialogResult>
if (result == DialogResult.Cancel)
{
// handle abort
}
I am creating a shell extension in C++ (ATL 9) using Visual Studio 2008. The Shell Extension creates a global MSXML2::IXMLDOMDocumentPtr object m_XmlDoc in the module class. This m_XmlDoc is then used in the extension by all classes to read xml document.
The problem that I am facing is with Internet explorer. When the Shell Extension is active and I open/close internet explorer, I get a debug dialog and IE crashes. The error message says "Unhandled exception at 0x6aac30f1 in iexplore.exe: 0xC0000005: Access violation reading location 0x03050970."
When I click "break" on the message window, It takes me to the "Release" method of COM Smart Pointer and the error seems to be on
m_pInterface->Release();
This call was made from Module's destructor and also the value of m_pInterface is not NULL. I think maybe internet explorer is using the XML DOM and the call to Release creates some problem in it.
MSXML2::IXMLDOMDocumentPtr m_XmlDoc;
In _AtlModule.Init() method
::CoInitialize(NULL);
m_XmlDoc.CreateInstance(MSXML2::CLSID_DOMDocument40);
dllMain code:
extern "C" BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
::CoInitialize(NULL);
if (dwReason == DLL_PROCESS_ATTACH)
{
_AtlModule.Init();
CreateImageLists();
::DisableThreadLibraryCalls(hInstance);
}
hInstance;
return _AtlModule.DllMain(dwReason, lpReserved);
}
the use of DisableThreadLibraryCalls is discouraged, you seen it?
There are at least two problems with your code as posted:
You're calling CoInitialize in DllMain.
You're creating a COM object in DllMain.
It wouldn't surprise me if you're doing something in CreateImageLists() which you also shouldn't be doing in DllMain.
Also, the reason that your crash was "fixed" by not using the smart pointer is because now you're not actually releasing the object anymore. Your code is broken, and not releasing the reference isn't a valid way to fix anything.
I would suggest that you read, and then re-read, the documentation for DllMain paying particular attention to the things you should never do within your implementation of the function. As you'll see right up front:
Warning There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL.
I suspect once you read it, and fix your code to create the COM object at a valid time, and release it at a valid time, your shell extension will stop crashing.
The problem was because of the COM Smart Pointer used for XmlDomDocument. I changed it to a normal pointer and it is working fine even in Vista.
This problem has a different behaviour in XP and Vista. In XP, I was getting an unhandled exception when I closed Internet Explorer. In Vista, I was not able to browse the virtual drive.
I'm writing a Win32 service in C++. I have a custom Assert macro that calls DebugBreak() (among other things). When I'm running my service under Vista, the service crashes when reaching the DebugBreak() call (an int 3 assembler opcode), showing the vista crash dialog. The error code is 80000003 (hardcoded breakpoint).
Normally I'm expecting that my service runs over the DebugBreak() call without doing anyting when no debugger is attached. Why is it crashing? Is there a possible setting to change so that it continues to run?
It is crashing because it is a breakpoint exception.
To be on the safe side you need to either check if a debugger is attached:
if(::IsDebuggerPresent()) ::DebugBreak();
or use try/except and return 1 (exceptionexecutehandler with an empty handler) for your breakpoint exception from the filter.
Normally I'm expecting that my service runs over the DebugBreak() call without doing anyting when no debugger is attached. Why is it crashing?
The MSDN Help for the DebugBreak function says, "If the process is not being debugged, the function uses the search logic of a standard exception handler. In most cases, this causes the calling process to terminate because of an unhandled breakpoint exception."
Is there a possible setting to change so that it continues to run?
You could try adding a Structured Exception Handler.
Alternatively, check some run-time flag before calling DebugBreak.