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.
Related
I've ported uavcan (dronecan) to stm32 nucleo-f413 board. The firmware is chibios based rtos.
During node initialization, execution is jumping to "_unhandled_exception" by executing the statement
mem_blocks_per_iface = allocator.getBlockCapacity() / (num_ifaces_ +
1U) + 1U;
inside the CanIOManager::CanIOManager constructor.
I've verified the callstack for the same and it is as below:
VectorFC() at vectors.S:1,021 0x80002da
<signal handler called>() at 0xfffffffd
uavcan::PoolAllocator<16384u, (unsigned char)48, char>::getBlockCapacity at dynamic_memory.hpp:80 0x801f110
uavcan::CanIOManager::CanIOManager() at uc_can_io.cpp:298 0x8012690
uavcan::Dispatcher::Dispatcher() at dispatcher.hpp:146 0x801bac6
uavcan::Scheduler::Scheduler() at scheduler.hpp:100 0x801bcac
uavcan::Node<16384u>::Node() at node.hpp:85 0x801d768
app::(anonymous namespace)::getNode at main.cpp:121 0x801caa6
configureNodeInfo() at main.cpp:159 0x801cb4c
I"m unable to identify the reason for exception handler.
I've tried varing the stack size, poolsize and blocksizes but still not helpful.
If anyone faced similar issue, kindly help. Thanks
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 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.
I have an application which makes use of winsock.
I/O part is handled on an other thread.
And I am using blocking select method for sockets.
But the point is that after 5-6 hours,my application gives 0xC00000FD exception, at the line of select function.
As far as I know, this exception occurs when there is recursion, or very large local variables. But neither of them is the case for me.
So do you have any idea why am I getting this exception?
Or any ideas to discover what actually causes exception?
many thanks
EDIT 2:
Dear All, I am very sorry but since reproducing the case takes long time, I just realized that this has not solved the problem.
Everything seems ok when stack overflow exception occurs at the line of select function.
I mean it is a server socket with a one client connected. So there is 2 socket in rset and 1 in wset. After selecting, I am checking all ready sockets and making required, read,write,accept. Timeout is 250 ms. Do you think can this be the problem? I don't want this function to be blocking so it is not null. But what will be the exact difference if I use {0,0}
An important hint is:
Same code was working without any problem, when client socket wasn't sending any data.
But when I started sending some data from client to server this problem occured.
I am sure that there is no problem with FD_SETs and FD_CLRs, I mean when client was not sending only 1(server) socket was in rset and 1(client) was in wset.
Anyway I had a look a lot of samples, but it seems that there is not a difference.
Please see local variables screenshot below(I have deleted name of executable, since it is a commercial product)
http://img192.imageshack.us/img192/1948/stackoverflow.jpg
And here is the call stack:
ntdll.dll!7c90df3a()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
mswsock.dll!71a53c9c()
ntdll.dll!7c90d26c()
mswsock.dll!71a55f9f()
mswsock.dll!71a55974()
ws2_32.dll!71ab314f()
xyz.exe!vm_socket_select(vm_socket * hds=0x04c1fb84, int nhd=1, int masks=7) Line 230 + 0x1b bytes C
xyz.exe!ND::nd_socket::SocketThreadProc() Line 173 + 0x12 bytes C++
xyz.exe!ND::nd_socket::ThreadRoutineStarter(void * u=0x07d63f90) Line 332 C++
xyz.exe!_callthreadstartex() Line 348 + 0x6 bytes C
xyz.exe!_threadstartex(void * ptd=0x011a3ce8) Line 326 + 0x5 bytes C
kernel32.dll!7c80b713()
I am waiting for any advice.
Many thanks
Have you tried stopping your program in a debugger after some time running? Then take a look at the stack it might give you a hint.
Recursion doesn't mean one of your functions call itself endlessly, it can't be more tricky and involve several layers before it comes back where it started.