|
|
I also am having the same issue. Load RC, Load Logbook, load DM and as soon as DM splash screen opens, Logbook crashes with Mini domp. Entered the minidump in the Mantis 2911 folder in the Dumps folder. Once Logbook closes a minidump for DM is created. Included that dump in the dumps folder. The dumps that I had created are indicated with my callsign as the prefix in the dump name. See the images attached to this Mantis record. See the dumps in the Dumps\Mantis 2911 folder.
KB3NPH LB Crash.jpg (134,983 bytes)
KB3NPH DM Crash.jpg (120,847 bytes) |
|
|
OSTicket #792745 has just reported the EXACT same issue with Logbook and DM. Waiting for him to forward the mini-dumps to add to the collection. |
|
|
What database is configured as the target for the Network Server in the Logbook options? Does that database exist? Can it be opened? Is it opened at the time of the crash? |
|
|
Incomplete information in this report has made a solid diagnosis challenging. I spent about three hours playing with the apps to try to reason out what's happening. I think I've made some progress, but I do wish the team would consider a more thorough approach as I think clearer and more detailed reports would substantially aid my progress. The dumps for the DM and Logbook closures don't appear to be available. Of the provided dumps, the most useful seem to be "KB3NPH HRDLogbook_20181001_162344.mdmp" and "OSTicket #548517 HRDLogbook_20181001_153133.mdmp", which contain the same stack pattern: (2cd4.2170): C++ EH exception - code e06d7363 (first/second chance not available) eax=00000000 ebx=13ad87b0 ecx=00000003 edx=00000000 esi=13ad8768 edi=13ad8778 eip=77ebb11c esp=1401d54c ebp=1401d558 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 ntdll!NtGetContextThread+0xc: 77ebb11c c20800 ret 8 0:026> .ecxr eax=1401f1a8 ebx=00000000 ecx=00000003 edx=00000000 esi=019a07bc edi=1401f254 eip=74a9ddc2 esp=1401f1a8 ebp=1401f204 iopl=0 nv up ei pl nz ac po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000212 KERNELBASE!RaiseException+0x62: 74a9ddc2 8b4c2454 mov ecx,dword ptr [esp+54h] ss:002b:1401f1fc=a8269849 0:026> kp *** Stack trace for last set context - .thread/.cxr resets it # ChildEBP RetAddr 00 1401f204 012262e3 KERNELBASE!RaiseException+0x62 01 1401f244 010df5eb HRDLogbook!_CxxThrowException(void * pExceptionObject = 0x1401f254, struct _s__ThrowInfo * pThrowInfo = 0x019a07bc)+0x5b [f:\dd\vctools\crt\crtw32\eh\throw.cpp @ 152] 02 1401f258 010fabef HRDLogbook!AfxThrowInvalidArgException(void)+0x19 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\except.cpp @ 228] 03 1401f2c0 010faf22 HRDLogbook!CMDIChildWnd::Create(wchar_t * lpszClassName = <Value unavailable error>, wchar_t * lpszWindowName = <Value unavailable error>, unsigned long dwStyle = <Value unavailable error>, struct tagRECT * rect = <Value unavailable error>, class CMDIFrameWnd * pParentWnd = <Value unavailable error>, struct CCreateContext * pContext = <Value unavailable error>)+0x177 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmdi.cpp @ 488] 04 1401f304 010af307 HRDLogbook!CMDIChildWnd::LoadFrame(unsigned int nIDResource = 0x103, unsigned long dwDefaultStyle = 0x40cf8000, class CWnd * pParentWnd = 0x00000000, struct CCreateContext * pContext = 0x1401f340)+0xbe [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmdi.cpp @ 613] 05 1401f320 01153fa2 HRDLogbook!CXTPFrameWndBase<CMDIChildWnd>::LoadFrame(unsigned int nIDResource = 0x103, unsigned long dwDefaultStyle = 0xcf8000, class CWnd * pParentWnd = 0x00000000, struct CCreateContext * pContext = 0x1401f340)+0x17 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpframewnd.h @ 231] 06 1401f354 0112cce6 HRDLogbook!CDocTemplate::CreateNewFrame(class CDocument * pDoc = 0x0816c260, class CFrameWnd * pOther = 0x00000000)+0x5d [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\doctempl.cpp @ 294] 07 1401f384 0112cc9e HRDLogbook!CMultiDocTemplate::OpenDocumentFile(wchar_t * lpszPathName = 0x00000000 "", int bAddToMRU = 0n1, int bMakeVisible = 0n1)+0x44 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\docmulti.cpp @ 126] 08 1401f398 016433c7 HRDLogbook!CMultiDocTemplate::OpenDocumentFile(wchar_t * lpszPathName = 0x00000000 "", int bMakeVisible = 0n1)+0x13 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\docmulti.cpp @ 110] 09 1401f3b0 01640e47 HRDLogbook!CHRDLogbookApp::OpenDocument(int iIdx = 0n0)+0x17 [c:\ham radio\logbook\hrdlogbook\hrdlogbook.cpp @ 1267] 0a 1401f400 01672d8b HRDLogbook!CHRDLogbookApp::FindOrOpenLogbookView(class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strDatabase = "My Logbook")+0x157 [c:\ham radio\logbook\hrdlogbook\hrdlogbook.cpp @ 1114] 0b 1401f434 01670741 HRDLogbook!CIpThread::FindOrOpenLogbookView(void)+0x9b [c:\ham radio\logbook\hrdlogbook\iplistener.cpp @ 853] 0c 1401f6dc 0167025d HRDLogbook!CIpThread::DispatchCommand(class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * strMessage = 0x1401f71c 60 '<', class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * strReply = 0x1401f714)+0x291 [c:\ham radio\logbook\hrdlogbook\iplistener.cpp @ 919] 0d 1401f89c 01673030 HRDLogbook!CIpThread::ProcessConnection(void)+0x23d [c:\ham radio\logbook\hrdlogbook\iplistener.cpp @ 1890] 0e 1401f8d8 012234c5 HRDLogbook!CIpThread::StartThreadPoint(class CIpThread * pThisObj = 0x08094700)+0xb0 [c:\ham radio\logbook\hrdlogbook\iplistener.cpp @ 725] 0f 1401f910 0122356c HRDLogbook!_callthreadstart(void)+0x1b [f:\dd\vctools\crt\crtw32\startup\thread.c @ 255] 10 1401f918 77bf8484 HRDLogbook!_threadstart(void * ptd = <Value unavailable error>)+0x56 [f:\dd\vctools\crt\crtw32\startup\thread.c @ 237] 11 1401f92c 77eb305a kernel32!BaseThreadInitThunk+0x24 12 1401f974 77eb302a ntdll!__RtlUserThreadStart+0x2f 13 1401f984 00000000 ntdll!_RtlUserThreadStart+0x1b This stack shows that the "network server" feature is trying to open a database in the logook for subequent use from the network server. The Logbook has a long history of poorly managing the configuration of database choices for its communication and background connection features, and the problem here is a side-effect of that issue. A thread is used to listen to a sockets which communicates with DM and other apps. The interface may need to connect to a database; if that database isn't already open in the Logbook, it tries to open it. (As far as I can tell, to work around this bug, all a user needs to do is manually open the database they have configured to be the target of the Network Server database operations.) When the logbook code tries to open the database on the background thread, it fails because MFC can't open a doc/view window on a thread other than the application's main thread. MFC ends up throwing an invalid argument exception, and that takes the app down. Because dumps for the other crashes aren't submitted, I'm not able to fix anything surrounding them. It's probable that the Logbook's crash causes DM780 to fall over; it would be great to make the communication code in the applications more robust, but the provided dumps don't give quite enough infomration to deduce what's going wrong in the applications at the time. |
|
|
Added Ticket #647992.rar to the related dumps folder. Customers comment: scenario1 -start of HRD rig control, this starts the DM780 automatically on my setup. DM780 is ok. -try to start logbook at DM780 top button bar -when asked for lotw or eQSL, I press "nothing" -logbook not started, creates minidump "HRDlogbook_20181002_220727.mdmp" -after a while DM780 closed itself (not responding, minidump seen "HRDLogbook_20181002_221628.mdmp") scenario2 -this scenario done immediately after scenario1 when rig control is still open -try to start logbook at HRD Rig control -this time HRD logbook starts ok -try to start DM780 top button bar in logbook -only startup screen of DM780 shows, program is not starting ok, see minidump "DigitalMaster_20181002_222018.mdmp" |
|
|
Repro on my computer. Start RC Start LB (have 2 databases) PD9FER Logbook and My Logbook (PD9FER Logbook is the one selected in Network server.) Start DM....No problems Close DM Select My Logbook to be the active database Start DM (Logbook crashes with a Minidump) Shut down DM Restart LB and selected PD9FER Logbook) Start DM (Now getting an error popup telling: Exception thrown in destructor (f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\array_s.ccp:83) Encountered a improper argument. After this DM closes Now restarted LB (Still with PD9FER Logbook active) and started DM and all is good without crash or errors. |
|
|
A workaround is available that doesn't require any code changes. This checkin has been made: https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4358 |
|
|
One fix would be, remove Network server And lets DM auto select the active DB And in DM build in an option to switch from DB so LB auto changes it to active just my 2 cents |
|
|
Details of the workaround are in this forum post: https://forums.hamradiodeluxe.com/node/47736?p=47832 |
|
|
HRDLogbook_20181003_182147.zip (19,114,960 bytes) |
|
|
Opened the Logbook and selected a non-default database. It did not appear in the Logbook. I.e a blank screen with the Cluster beneath. Opened DM780 and a Logbook mini dump was created. Attached here. |
|
|
Ticket#932554 Logbook crash with minidump added to the Mantis 2911 folder. |
|
|
I believe this is fixed in 890. |
|
|
Same problem with build 890 |
|
|
Same problem in 6.4.890. Load RC loads fine, then from the RC screen start the Logbook. Logbook starts fine. From Logbook screen start DM, splash screen comes up for DM then crashes with Mini dump. Minidump added to 2911 dump folder "KB3NPH - 890 Alpha DigitalMaster_20181004_124255.mdmp" Shut HRD down and start in this order. Load RC, loads fine, Load DM from RC gui, DM loads fine. Load Logbook from DM GUI and immediately get LB CRASH with mini=dump. Entered this dump in the 2911 dump folder "KB3NPH - 890 Alpha HRDLogbook_20181004_125448.mdmp" |
|
|
Seems to be fixed with build 891 At least no errors or crashes when I do the Repro steps, |
|
|
Tested 6.4.0.891 and all appears to be working correctly on my computer. Will try sending it to a couple customers who are having the problem and see if it resolves it for them before final confirmation that it is fixed. |
|
|
Ran the procedure at #6264 and had no problems. Fixed for me. |
- Anonymous
