I have a DirectX9 application that sporadically runs into a hang in WM_WINDOWPOSCHANGED. The hang occurs only rarely when alt+tabbing into and out of fullscreen exclusive mode.
The application is hung because the main window message processing thread is stuck at WaitForSingleObject() in the DefWindowProc handler. Other threads we have created are operating normally.
Call Stack on Stuck Main Thread:
ntdll.dll!_NtWaitForSingleObject#12() + 0x15 bytes
ntdll.dll!_NtWaitForSingleObject#12() + 0x15 bytes
kernel32.dll!_WaitForSingleObjectExImplementation#12() + 0x43 bytes
kernel32.dll!_WaitForSingleObject#8() + 0x12 bytes
d3d9.dll!WindowProc() + 0x27e95 bytes
user32.dll!_InternalCallWinProc#20() + 0x23 bytes
user32.dll!_UserCallWinProcCheckWow#32() + 0xb7 bytes
user32.dll!_DispatchClientMessage#24() + 0x51 bytes
user32.dll!___fnDWORD#4() + 0x2b bytes
ntdll.dll!_KiUserCallbackDispatcher#12() + 0x2e bytes
user32.dll!_NtUserMessageCall#28() + 0x15 bytes
user32.dll!_RealDefWindowProcWorker#24() + 0x26afe bytes
user32.dll!_RealDefWindowProcW#16() + 0x2a bytes
uxtheme.dll!_ThemeDefWindowProc() + 0x152 bytes
uxtheme.dll!_ThemeDefWindowProcW#16() + 0x18 bytes
user32.dll!_DefWindowProcW#16() + 0x805 bytes
> Player.exe!cnWindowProc(HWND__ * hWnd=0x006507f4, unsigned int message=0x00000047, unsigned int wParam=0x00000000, long lParam=0x0034eea8) Line 502 + 0x18 bytes C++
I am wondering what Windows is waiting for here. DirectX is created and owned by a separate thread, but that thread is not stuck. We seem to be handling things correctly for lost devices (freeing up video memory resources and calling Reset()).
If anyone has ideas on why windows is hanging here, I would appreciate it.
Usually when I see this problem it is because SetWindowPos() needs to be called after setting the window style with a SetWindowLong() function. Changes will not be updated until SetWindowPos() is called, as detailed here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms633591%28v=vs.85%29.aspx
It does not always seem to crash without calling SetWindowPos(), but will sometimes. I am not sure why the result is usually so sporadic. Either way the results will not update without that call.
Related
I am working with a device (the wiimote) that takes commands through the DATA pipe, and only accepts command packets that are EXACTLY as long as the command itself. For example, it will accept:
0x11 0x10
but it will not accept:
0x11 0x10 0x00 0x00 0x00 ... etc.
This is a problem on windows, as WriteFile() on windows requires that the byte[] passed to it is at least as long as caps.OutputReportByteLength. On mac, where this limitation isn't present, my code works correctly. Here is the code from hid.c that causes this issue:
/* Make sure the right number of bytes are passed to WriteFile. Windows
expects the number of bytes which are in the _longest_ report (plus
one for the report number) bytes even if the data is a report
which is shorter than that. Windows gives us this value in
caps.OutputReportByteLength. If a user passes in fewer bytes than this,
create a temporary buffer which is the proper size. */
if (length >= dev->output_report_length) {
/* The user passed the right number of bytes. Use the buffer as-is. */
buf = (unsigned char *) data;
} else {
/* Create a temporary buffer and copy the user's data
into it, padding the rest with zeros. */
buf = (unsigned char *) malloc(dev->output_report_length);
memcpy(buf, data, length);
memset(buf + length, 0, dev->output_report_length - length);
length = dev->output_report_length;
}
res = WriteFile(dev->device_handle, buf, length, NULL, &ol);
Removing the above code, as mentioned in the comments, results in an error from WriteFile().
Is there any way that I can pass data to the device of arbitrary size? Thanks in advance for any assistance.
Solved. I used a solution similar to the guys over at Dolphin, a Wii emulator. Apparently, on the Microsoft bluetooth stack, WriteFile() doesn't work correctly, causing the Wiimote to return with an error. By using HidD_SetOutputReport() on the MS stack and WriteFile() on the BlueSoleil stack, I was able to successfully connect to the device (at least on my machine).
I haven't tested this on the BlueSoleil stack, but Dolphin is using this method so it is safe to say it works.
Here is a gist containing an ugly implementation of this fix:
https://gist.github.com/Flafla2/d261a156ea2e3e3c1e5c
I'm writing an extension to MFC app with use of ZMQ (zmq.hpp). When I'm trying to unload my DLL from the app, the zmq_ctx_destroy() function hangs forever.
I have found a similar issue but there is no answer.
I've tried to debug it and found out that it stops in function zmq::thread_t::stop() on the first line:
DWORD rc = WaitForSingleObject (descriptor, INFINITE);
It hung even without sending anything. Simplified code looks like this:
zmq::context_t context(1);
zmq::socket_t socket(context, ZMQ_REQ);
socket.connect(ENDPOINT.c_str());
Socket and context destroyed when leaving scope.
Call Stack:
libzmq-v100-mt-gd-4_0_4.dll! zmq::thread_t::stop() Line 56 + 0x17 bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq::select_t::~select_t() Line 57 + 0x13 bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq::select_t::`scalar deleting destructor'() + 0x2c bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq::io_thread_t::~io_thread_t() Line 39 + 0x37 bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq::io_thread_t::`scalar deleting destructor'() + 0x2c bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq::ctx_t::~ctx_t() Line 82 + 0x49 bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq::ctx_t::`scalar deleting destructor'() + 0x2c bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq::ctx_t::terminate() Line 153 + 0x3d bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq_ctx_term(void * ctx_) Line 171 + 0xa bytes C++
libzmq-v100-mt-gd-4_0_4.dll! zmq_ctx_destroy(void * ctx_) Line 242 C++
DataReader.dll! zmq::context_t::close() Line 309 + 0xe bytes C++
DataReader.dll! zmq::context_t::~context_t() Line 303 C++
The MFC app has a mechanism to run specifically created DLLs. This DLL is based on CWinApp, all DLL-specific initialization code in the InitInstance member function and termination code in ExitInstance. So this JIRA issue should not be the case.
After a couple of days I found out that the app also relies on sockets as ZMQ. So at the end of its life ZMQ context was waiting for closing of all opened sockets in the process, but MFC app continues to use its opened sockets. That was the reason why zmq_ctx_destroy() function hangs forever.
Solution for cases like this one (when app uses sockets as well and you need to add some functionality based on ZMQ).
Create a new process. This process will create a ZMQ context and send/receive all messages. Data from dll could be passed to that process via Windows messages or shared memory.
I have this legacy application which I've been trying to get up and running.
It has some dependencies on an old DirectX SDK version which can only be installed on WinXP (or prior) so I used a virtual machine of mine and successfully built the application. However, due to limitations of the virtual graphics hardware the application is not rendering its graphics correctly, but that was just expected. The rest of the application (UI-interaction and such) seems to work just fine on the virtual machine (32-bit Windows XP).
When I try to to run the applcation on my physical machine, 64-bit Windows 7, it hangs in an early state. I used some debug output to track down exactly where it hangs, and it's when CDialog::Create is called for creating a modeless dialog.
I finally tried to start it on my laptop, 32-bit Windows 8.1, and it worked. I'm thinking that it should have something to do with x86 vs x64, but of course I cannot be sure.
Has anyone come across something similar? I've googled a lot on CDialog::Create hanging, and found some interesting threads, but everything looks correct in code, and well, it runs, but only on 32-bit machines.
Update:
I managed to build the application in VS2010 by removing a bunch of code. When I debug the application the callstack shows that it hangs on the CreateDialogIndirect call in CWnd::CreateDlgIndirect.
I found a thread regarding this, but it didn't solve anything, AfxOleInit is being called.
This discussion sounds more interesting but I haven't gotten around to try the proposed solution yet.
Update 2:
Setting the DEP to AlwaysOff didn't change anything.
The complete call-stack looks like this:
ntdll.dll!_NtDelayExecution#8() + 0x15 bytes
ntdll.dll!_NtDelayExecution#8() + 0x15 bytes
KernelBase.dll!_Sleep#4() + 0xf bytes
nvoglv32.dll!6955244d()
[Frames below may be incorrect and/or missing, no symbols loaded for nvoglv32.dll]
nvoglv32.dll!68e3e2e7()
nvoglv32.dll!6954d2ad()
nvoglv32.dll!6954d37c()
user32.dll!_DispatchHookA#16() + 0x56 bytes
user32.dll!_fnHkINLPCWPSTRUCTA#24() + 0x66 bytes
user32.dll!___fnINLPCREATESTRUCT#4() + 0x68 bytes
ntdll.dll!_KiUserCallbackDispatcher#12() + 0x2e bytes
user32.dll!_NtUserCreateWindowEx#60() + 0x15 bytes
user32.dll!_VerNtUserCreateWindowEx#52() + 0x18a bytes
user32.dll!_InternalCreateDialog#28() + 0x42a bytes
user32.dll!_CreateDialogIndirectParamAorW#24() + 0x33 bytes
user32.dll!_CreateDialogIndirectParamA#20() + 0x1b bytes
Viewer.exe!CWnd::CreateDlgIndirect(const DLGTEMPLATE * lpDialogTemplate, CWnd * pParentWnd, HINSTANCE__ * hInst) Line 370 C++
Viewer.exe!CDialog::CreateIndirect(const DLGTEMPLATE * lpDialogTemplate, CWnd * pParentWnd, void * lpDialogInit, HINSTANCE__ * hInst) Line 262 + 0x17 bytes C++
Viewer.exe!CDialog::CreateIndirect(void * hDialogTemplate, CWnd * pParentWnd, HINSTANCE__ * hInst) Line 240 + 0x10 bytes C++
Viewer.exe!CDialog::Create(const char * lpszTemplateName, CWnd * pParentWnd) Line 223 C++
Viewer.exe!CToolDialog::CreateModeless(CWnd * pParent) Line 41
Viewer.exe!CMainFrame::CreateTools() Line 176 + 0x17 bytes C++
Viewer.exe!CViewerApp::OnIdle(long lCount) Line 1293 C++
Viewer.exe!CWinThread::Run() Line 621 + 0xa bytes C++
Viewer.exe!AfxWinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nCmdShow) Line 47 + 0x7 bytes C++
Viewer.exe!__tmainCRTStartup() Line 275 + 0x1c bytes C
kernel32.dll!#BaseThreadInitThunk#12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart#8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart#8() + 0x1b bytes
Update 3
The application is usually started using a C# launcher application (to be able to select user profiles and other startup settings) and starting it this way it hangs. Also, starting it from the file explorer (or command prompt) it hangs. BUT, if I start it directly from VS2010 using F5, it runs...
SOLVED
I updated my graphics driver, and everything works great.
I updated my graphics driver, and everything works great.
i have written dialogue based application .and on init of dialogue i have added multiple Frames and opening as FramewndEx as main-entry of point of application.
an Action of alt +tab application got crashed suddenly and its showing cursor at crtexe.c
comctl32.dll!MasterSubclassProc() + 0x4f81 bytes
user32.dll!UserCallWinProcCheckWow() + 0x13e bytes
user32.dll!DispatchMessageWorker() + 0x1a7 bytes
mfc100u.dll!AfxInternalPumpMessage() + 0x52 bytes
mfc100u.dll!CWinThread::Run() + 0x6f bytes
mfc100u.dll!AfxWinMain() + 0xac bytes
RockEye.exe!__tmainCRTStartup() Line 547 + 0x24 bytes C
kernel32.dll!BaseThreadInitThunk() + 0x1a bytes
ntdll.dll!RtlUserThreadStart() + 0x21 bytes
i am new to this type of situations. i am very struck here.
We have a legacy COM+ dll that is called by an old ASP application. It is periodically crashing, and the call stack is very strange looking
It appears that a call to DllUnregisterServer and to CoInstall appear within the call stack (we don't dynamically install/uninstall anything within the code -- it's just querying a database).
I am wondering if it is possible that MSI "file protection" is kicking in and causing the crash. Do you think that's possible? any way I can dig up more information? (it's an old VFP applicaiton, so I don't think I can get proper debug symbols)
Here's the call stack:
Call Stack:
vfp9t! + 0x2272f
vfp9t!VFPDllGetClassObject + 0xb6
ctcvccomasyncproxy!DllGetClassObject + 0x3e
ole32!CoInitializeSecurity + 0x5ff5
ole32!CoInitializeSecurity + 0x5bdc
ole32!CoGetTreatAsClass + 0x2a2
ole32!CoInitializeSecurity + 0x3a2b
COMSVCS!DispManGetContext + 0xbc07
ole32!CoInitializeSecurity + 0x3a2b
ole32!CoInstall + 0x6ed
ole32!CoQueryAuthenticationServices + 0x21aa
ole32!CoQueryAuthenticationServices + 0x2c56
ole32!CoGetContextToken + 0xd48d
ole32!CreateStreamOnHGlobal + 0x1b7c
ole32!CoCreateObjectInContext + 0xd9f
ole32!CoInstall + 0x903
ole32!CoGetContextToken + 0x12f5b
RPCRT4!NdrServerInitialize + 0x1fc
RPCRT4!NdrStubCall2 + 0x217
RPCRT4!CStdStubBuffer_Invoke + 0x82
ole32!StgGetIFillLockBytesOnFile + 0x13b27
ole32!StgGetIFillLockBytesOnFile + 0x13ad4
ole32!DcomChannelSetHResult + 0xaab
ole32!DcomChannelSetHResult + 0x495
ole32!CoFreeUnusedLibrariesEx + 0xb06
ole32!StgGetIFillLockBytesOnFile + 0x139e1
ole32!StgGetIFillLockBytesOnFile + 0x13872
ole32!StgGetIFillLockBytesOnFile + 0x12d59
ole32!CoFreeUnusedLibrariesEx + 0x9f5
ole32!CoFreeUnusedLibrariesEx + 0x9c0
USER32!LoadCursorW + 0x4cf5
USER32!LoadCursorW + 0x4e86
USER32!TranslateMessageEx + 0x10d
USER32!DispatchMessageW + 0xf
COMSVCS!DllUnregisterServer + 0x270
COMSVCS!DllUnregisterServer + 0x180
COMSVCS!DllUnregisterServer + 0xc6c
COMSVCS!DllUnregisterServer + 0xf4d
msvcrt!_endthreadex + 0xa3
kernel32!GetModuleHandleA + 0xdf
ole32!CoInstall + 0x6ed
The +0x6ed offset is an important 'quality' indicator. What it tells you is that the return address is 1773 bytes from the known address of CoInstall. That's rather a lot. The stack trace builder just didn't have any other known address that was closer so it could only offer CoInstall as a guess. Once the offset goes beyond 0x100, the odds that the code is actually part of the indicated known function start to dwindle rapidly.
There are a lot of entries in the trace that have huge offsets. Making the entire trace rather low quality. Editing the stack trace and leaving only good quality lines in place:
vfp9t!VFPDllGetClassObject + 0xb6
ctcvccomasyncproxy!DllGetClassObject + 0x3e
...
RPCRT4!CStdStubBuffer_Invoke + 0x82
...
USER32!DispatchMessageW + 0xf
Which is a pretty standard stack trace for a cross-apartment request to get a COM object class factory. Why it failed is not guessable, you don't have debug symbols for foxpro and didn't document the HRESULT.
That stack dump does not appear to be plausible. It is almost certainly not useful.
I suggest writing an unhandled exception handler and trying to get it to crash again. Your handler can try to do a better stack dump or even a proper crash dump.
See
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680634.aspx
http://www.microsoft.com/msj/0197/Exception/Exception.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680360.aspx
The handler would be in your code that calls the dll code.