View Issue Details

IDProjectCategoryView StatusLast Update
00033051 - BacklogBugpublic2019-05-01 09:32
ReporterPD9FERAssigned To 
PrioritynormalSeverityminorReproducibilityunable to reproduce
Status newResolutionopen 
Summary0003305: Logbook crashes on Callsign Lookup
DescriptionWhen doing a lookup from the ALE, logbooks crashes and creates a Minidump.
Not sure if it is really a Bug or some issue on customers OS.
Steps To ReproduceWith QRZ configured
Open ALE
Do a Callsign Lookup > Crash

With QRZ removed (only Logbook and Country List active)
Open ALE Do a Callsign Lookup and Add to Log > Takes 10 to 15 seconds followed by a crash.
 
Not able to repro on my machines.
Additional InformationTicket #410299

Been in remote with the customer.
Tried all I could but could not get it fixed.

Mini dumps are on Google Drive Dumps folder with this Mantis ID.

Maybe Mike B can see what is happening and point me to where to look at.
TagsNo tags attached.
ModuleLogbook
Sub-ModuleALE Window
TestingNot Started

Activities

K7ZCZ

2019-04-23 12:35

administrator   ~0007879

Looks like these are all with build 6.5.0.207.

0:000> lmDvmHRDLogbook
Browse full module list
start    end        module name
00080000 019e4000   HRDLogbook   (deferred)             
    Image path: C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe\HRDLogbook.exe
    Image name: HRDLogbook.exe
    Browse all global symbols  functions  data
    Timestamp:        Sun Mar 31 07:36:44 2019 (5CA0D07C)
    CheckSum:         0173FA03
    ImageSize:        01964000
    File version:     6.5.0.207
    Product version:  6.5.0.207
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

PD9FER

2019-04-23 12:59

updater   ~0007880

Yes it is 207
Please give me any directions to look at to solve the issue if this is not a Bug.

K7ZCZ

2019-04-23 14:31

administrator   ~0007881

These files were found in the given Google Drive directory:

HRDLogbook_20190415_144924.mdmp
HRDLogbook_20190415_145014.mdmp
HRDLogbook_20190415_151743.mdmp
HRDLogbook_20190415_151947.mdmp
HRDLogbook_20190415_152644.mdmp


The first four have the same call stack, which appears to be related to connecting the Logbook to Rig Control from the Radio Dialog:

0:000> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 003eede0 00a8d6df HRDInterface001!HRDInterfaceConnect(wchar_t * lpszAddress = 0x0531cc78 "localhost", unsigned short wPort = 0x1e81)+0x438 [c:\hrd65\digital master\hrdinterface001\hrdinterface001.cpp @ 136] 
01 003ef77c 00bf7bff HRDLogbook!CRadioDlg::Connect(void)+0x1af [c:\hrd65\logbook\hrdlogbook\radiodlg.cpp @ 335] 
02 003ef790 00bf79fb HRDLogbook!_AfxDispatchCmdMsg(class CCmdTarget * pTarget = 0x074164c0, unsigned int nID = 0x80fa, int nCode = 0n0, <function> * pfn = 0x00a8d1b0, void * pExtra = 0x00000000, unsigned int nSig = 0x3a, struct AFX_CMDHANDLERINFO * pHandlerInfo = 0x00000000)+0x4e [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 78] 
03 003ef7c8 00bfcbbd HRDLogbook!CCmdTarget::OnCmdMsg(unsigned int nID = 0x80fa, int nCode = 0n0, void * pExtra = 0x00000000, struct AFX_CMDHANDLERINFO * pHandlerInfo = 0x00000000)+0x154 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 372] 
04 003ef7f0 00bf2b37 HRDLogbook!CDialog::OnCmdMsg(unsigned int nID = 0x80fa, int nCode = 0n0, void * pExtra = 0x00000000, struct AFX_CMDHANDLERINFO * pHandlerInfo = 0x00000000)+0x1c [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 85] 
05 003ef840 00bf3869 HRDLogbook!CWnd::OnCommand(unsigned int wParam = 0x80fa, long lParam = 0n0)+0x61 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2800] 
06 003ef910 00881af6 HRDLogbook!CWnd::OnWndMsg(unsigned int message = 0x111, unsigned int wParam = 0x80fa, long lParam = 0n0, long * pResult = 0x003ef94c)+0x45 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2113] 
07 003ef92c 00bf512c HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0x111, unsigned int wParam = 0x80fa, long lParam = 0n0, long * pResult = 0x003ef94c)+0x46 [c:\hrd65\codejock software\mfc\xtreme toolkitpro v18.6.0\source\commandbars\xtpdialogbase.h @ 203] 
08 003ef950 00bf038f HRDLogbook!CWnd::WindowProc(unsigned int message = 0x111, unsigned int wParam = 0x80fa, long lParam = 0n0)+0x2d [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2099] 
09 003ef9c4 00bf0b50 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x074164c0 {hWnd={...}}, struct HWND__ * hWnd = 0x0003010c, unsigned int nMsg = 0x111, unsigned int wParam = 0x80fa, long lParam = 0n0)+0xc6 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 268] 
0a 003ef9e4 76b262fa HRDLogbook!AfxWndProc(struct HWND__ * hWnd = 0x0003010c, unsigned int nMsg = 0x111, unsigned int wParam = 0x80fa, long lParam = 0n0)+0x34 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 417] 
0b 003efa10 76b26d3a user32!InternalCallWinProc+0x23
0c 003efa88 76b277c4 user32!UserCallWinProcCheckWow+0x109
0d 003efae8 76b2788a user32!DispatchMessageWorker+0x3b5
0e 003efaf8 00bfabe5 user32!DispatchMessageW+0xf
0f 003efb08 00bfb2d9 HRDLogbook!AfxInternalPumpMessage(void)+0x3e [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
10 003efb24 01114037 HRDLogbook!CWinThread::Run(void)+0x69 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 629] 
11 003efb3c 00d4d9e1 HRDLogbook!AfxWinMain(struct HINSTANCE__ * hInstance = 0x00860000, struct HINSTANCE__ * hPrevInstance = 0x00000000, wchar_t * lpCmdLine = 0x02351e4e "", int nCmdShow = 0n1)+0x93 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 61] 
12 (Inline) -------- HRDLogbook!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
13 003efb88 75b8336a HRDLogbook!__scrt_common_main_seh(void)+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
14 003efb94 77a59902 kernel32!BaseThreadInitThunk+0xe
15 003efbd4 77a598d5 ntdll!__RtlUserThreadStart+0x70
16 003efbec 00000000 ntdll!_RtlUserThreadStart+0x1b



That doesn't match the scenario or the repro steps presented in the issue so far.

The last dump file, HRDLogbook_20190415_152644.mdmp, has a clal stack that's very short and looks like is a crash while the lookup thread is tying to lock its work list:

0:025> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 148df854 012bcb3c HRDLogbook!CSingleLock::Lock(unsigned long dwTimeOut = 0xffffffff)+0xf [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\mtex.cpp @ 108] 
01 148df88c 013c3816 HRDLogbook!CLibBackgroundProcessingThread::DoWork(void)+0x5c [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 187] 
02 (Inline) -------- HRDLogbook!CThinThread::Run+0x55 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 189] 
03 148df8cc 01a03680 HRDLogbook!CThinThread::Start(void * pv = 0x0033eb48)+0x96 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 228] 
04 (Inline) -------- HRDLogbook!invoke_thread_procedure+0xd [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 
05 148df908 757c336a HRDLogbook!thread_start<unsigned int (void * parameter = 0x162a06c0)+0x57 [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
06 148df914 77a09902 kernel32!BaseThreadInitThunk+0xe
07 148df954 77a098d5 ntdll!__RtlUserThreadStart+0x70
08 148df96c 00000000 ntdll!_RtlUserThreadStart+0x1b


There's not too much to go on in this stack, so I'll have to dig a lot more.

But before I do, I want to be perfectly sure that all of these dump files really are from the given repro steps and no mistake was made in capturing them or documenting them.

PD9FER

2019-04-23 14:55

updater   ~0007882

Shall I advise the Customer to set the Large dump?
I make sure of the same repro steps

K7ZCZ

2019-04-23 16:34

administrator   ~0007883

A large dump might be useful, but I think the more pressing issue is figuring out how the radio dialog connection is involved.

PD9FER

2019-04-24 03:44

updater   ~0007885

Large dumps provided in the dumps folder.
They happened with these steps:
With QRZ lookup configured
Open ALE
Do a Callsign Lookup

K7ZCZ

2019-04-24 09:05

administrator   ~0007886

The large dump files are these, all from build 6.5.0.207:

HRDLogbook_20190423_205708.mdmp
HRDLogbook_20190423_210930.mdmp
HRDLogbook_20190423_211444.mdmp


don't show the crash at startup shown in the other dump files. They fit the worker-thread crash pattern seen in HRDLogbook_20190415_152644.mdmp.

I guess the best way to proceed is to ignore the startup crashes--since repro steps for them don't seem to be available--and focus on the worker-thread crash that happens in response to the lookup operation.

K7ZCZ

2019-04-24 14:43

administrator   ~0007887

The call stacks shows that the users is opening the ALE by double-clicking on an existing entry. This isn't mentioned in the repro steps, which don't make it clear how the ALE was opened.

The dumps show that the customer is using Windows 7:

0:017> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
6.1.7601.18015 (win7sp1_gdr.121129-1432)
Machine Name:
Debug session time: Tue Apr 23 13:57:08.000 2019 (UTC - 7:00)
System Uptime: not available
Process Uptime: 0 days 0:04:18.000
  Kernel time: 0 days 0:00:03.000
  User time: 0 days 0:00:30.000

K7ZCZ

2019-04-24 15:25

administrator   ~0007888

Digging into HRDLogbook_20190423_211444.mdmp, we see this crashing stack:

0:024> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 (Inline) -------- -------- -------- -------- HRDLogbook!CLibBackgroundProcessingThread::ProcessData+0xc8 [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 284] 
01 1482faa4 01113816 7731a68f 163b5110 01113780 HRDLogbook!CLibBackgroundProcessingThread::DoWork+0x140 [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 209] 
02 (Inline) -------- -------- -------- -------- HRDLogbook!CThinThread::Run+0x55 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 189] 
03 1482fae4 01753680 13924254 7731a74b 00000000 HRDLogbook!CThinThread::Start+0x96 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 228] 
04 (Inline) -------- -------- -------- -------- HRDLogbook!invoke_thread_procedure+0xd [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 
05 1482fb20 74c5336a 163b5110 1482fb6c 77139902 HRDLogbook!thread_start<unsigned int (__stdcall*)(void *)>+0x57 [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
06 1482fb2c 77139902 163b5110 63864f09 00000000 kernel32!BaseThreadInitThunk+0xe
07 1482fb6c 771398d5 01753629 163b5110 00000000 ntdll!__RtlUserThreadStart+0x70
08 1482fb84 00000000 01753629 163b5110 00000000 ntdll!_RtlUserThreadStart+0x1b



Looks like the main thread in t application is closing the ALE window and has asked the background thread to shut down:

0:024> ~*kb

   0  Id: f94.1784 Suspend: 0 Teb: 7efdd000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 0041f470 753915ce 00000af4 00000000 0041f4b8 ntdll!NtWaitForSingleObject+0x15
01 0041f4dc 74c51194 00000af4 0000ea60 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
02 0041f4f4 74c51148 00000af4 0000ea60 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
03 0041f508 0127be69 00000af4 0000ea60 0041f530 kernel32!WaitForSingleObject+0x12
04 0041f518 0127bf67 0000ea60 0042f544 0042f544 HRDLogbook!CSyncObject::Lock+0xf [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\mtcore.cpp @ 42] 
05 0041f530 0100caa5 0000ea60 63f2a907 0042f544 HRDLogbook!CSingleLock::Lock+0x1e [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\mtex.cpp @ 109] 
06 (Inline) -------- -------- -------- -------- HRDLogbook!CThinThread::WaitForThreadFinished+0x21 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 156] 
07 0041f56c 0100c952 63f2a9fb ffffffff 0041f630 HRDLogbook!CLibBackgroundProcessingThread::CloseDown+0xc5 [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 142] 
08 0041f590 0101f095 63f2a9d3 7fffffff 07b7a0d0 HRDLogbook!CLibBackgroundProcessingThread::~CLibBackgroundProcessingThread+0x32 [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 101] 
09 0041f5b8 00fdc4a0 63f1ab87 7fffffff 07b7a0d0 HRDLogbook!CLogbookFull::~CLogbookFull+0x205 [c:\hrd65\logbook\hrdlogbook\logbookfull.cpp @ 908] 
0a 0042f7ec 00fdb888 00000000 00fdb860 07b7a0d0 HRDLogbook!CHRDLogbookView::ModifyEntry+0xb30 [c:\hrd65\logbook\hrdlogbook\hrdlogbookview.cpp @ 2764] 
0b (Inline) -------- -------- -------- -------- HRDLogbook!CHRDLogbookView::OnLogbookModify+0x20 [c:\hrd65\logbook\hrdlogbook\hrdlogbookview.cpp @ 2595] 
0c 0042f800 01253da0 00000001 00000203 0000001e HRDLogbook!CHRDLogbookView::OnLButtonDblClk+0x28 [c:\hrd65\logbook\hrdlogbook\hrdlogbookview.cpp @ 2564] 
0d 0042f8d4 0125512c 00000203 00000001 001e0203 HRDLogbook!CWnd::OnWndMsg+0x57c [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2698] 
0e 0042f8f8 0125038f 00000203 00000001 001e0203 HRDLogbook!CWnd::WindowProc+0x2d [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2099] 
0f 0042f96c 01250b50 07b7a0d0 00430946 00000203 HRDLogbook!AfxCallWndProc+0xc6 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 268] 
10 0042f98c 74b162fa 00430946 00000203 00000001 HRDLogbook!AfxWndProc+0x34 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 417] 
11 0042f9b8 74b16d3a 01250b1c 00430946 00000203 user32!InternalCallWinProc+0x23
12 0042fa30 74b177c4 00000000 01250b1c 00430946 user32!UserCallWinProcCheckWow+0x109
13 0042fa90 74b1788a 01250b1c 00000000 0042facc user32!DispatchMessageWorker+0x3b5
14 0042faa0 0125abe5 0079f648 00000000 0125b26b user32!DispatchMessageW+0xf
15 0042fab0 0125b2d9 01a64c40 012846b4 ffffffff HRDLogbook!AfxInternalPumpMessage+0x3e [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 183] 
16 0042facc 01774037 00000000 01c7ee58 7efde000 HRDLogbook!CWinThread::Run+0x69 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 629] 
17 0042fae4 013ad9e1 00ec0000 00000000 00711e4c HRDLogbook!AfxWinMain+0x93 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 61] 
18 (Inline) -------- -------- -------- -------- HRDLogbook!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
19 0042fb30 74c5336a 7efde000 0042fb7c 77139902 HRDLogbook!__scrt_common_main_seh+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
1a 0042fb3c 77139902 7efde000 77464f19 00000000 kernel32!BaseThreadInitThunk+0xe
1b 0042fb7c 771398d5 013ada65 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
1c 0042fb94 00000000 013ada65 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b


But there's another instance of the CLibBackgroundProcessingThread thread which is waiting for a response from a website after doing a QRZ lookup request:

  29  Id: f94.144c Suspend: 0 Teb: 7ef58000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 145ef6c4 753915ce 00000494 00000000 00000000 ntdll!NtWaitForSingleObject+0x15
01 145ef730 74c51194 00000494 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x98
02 145ef748 74c51148 00000494 ffffffff 00000000 kernel32!WaitForSingleObjectExImplementation+0x75
03 145ef75c 744cd82c 00000494 ffffffff 000003e5 kernel32!WaitForSingleObject+0x12
04 145ef7a4 744cd8af 15595808 00000000 0785ed10 winhttp!HTTP_USER_REQUEST::_HandleSyncPending+0xa0
05 145ef7cc 744c7b8f 00000000 00000000 00000000 winhttp!HTTP_USER_REQUEST::SendRequest+0x21b
06 145ef89c 72132f65 0785ed10 00000000 00000000 winhttp!WinHttpSendRequest+0x245
07 145ff938 7213268a 145ff9b8 145ff9ac 145ff9a8 HRDStation!GetWebFile+0x595 [c:\hrd65\hrdstation\getwebfile.cpp @ 348] 
08 145ff954 6f452238 162ee4f8 145ff9b8 145ff9ac HRDStation!HRDGetWebFileAndHeadersW+0x1a [c:\hrd65\hrdstation\getwebfile.cpp @ 63] 
09 145ff9cc 6f45a0e2 00000001 778b28a8 ffffffff HRDLogbookCallsignLookup!CGetWebPage::Get+0x138 [c:\hrd65\logbook\hrdlogbookcallsignlookup\getwebpage.cpp @ 73] 
0a (Inline) -------- -------- -------- -------- HRDLogbookCallsignLookup!CGetWebPage::GetAsXML+0x11 [c:\hrd65\logbook\hrdlogbookcallsignlookup\getwebpage.cpp @ 54] 
0b 145ffb94 6f45b227 145ffc2c 145ffc84 145ffc80 HRDLogbookCallsignLookup!QRZXMLLookup+0x9d2 [c:\hrd65\logbook\hrdlogbookcallsignlookup\hrdlogbookcallsignlookup.cpp @ 2533] 
0c 145ffe68 0100cbcf 13ae8aa0 00020002 1634ec60 HRDLogbookCallsignLookup!HRDLogbookCallsignLookupW+0x627 [c:\hrd65\logbook\hrdlogbookcallsignlookup\hrdlogbookcallsignlookup.cpp @ 2736] 
0d (Inline) -------- -------- -------- -------- HRDLogbook!CLibBackgroundProcessingThread::CallsignLookup+0x2e [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 504] 
0e (Inline) -------- -------- -------- -------- HRDLogbook!CLibBackgroundProcessingThread::ProcessData+0x77 [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 278] 
0f 145ffeac 01113816 77eca287 1623f280 01113780 HRDLogbook!CLibBackgroundProcessingThread::DoWork+0xef [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 209] 
10 (Inline) -------- -------- -------- -------- HRDLogbook!CThinThread::Run+0x55 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 189] 
11 145ffeec 01753680 0042f544 77eca343 00000000 HRDLogbook!CThinThread::Start+0x96 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 228] 
12 (Inline) -------- -------- -------- -------- HRDLogbook!invoke_thread_procedure+0xd [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 
13 145fff28 74c5336a 1623f280 145fff74 77139902 HRDLogbook!thread_start<unsigned int (__stdcall*)(void *)>+0x57 [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
14 145fff34 77139902 1623f280 635b4b11 00000000 kernel32!BaseThreadInitThunk+0xe
15 145fff74 771398d5 01753629 1623f280 00000000 ntdll!__RtlUserThreadStart+0x70
16 145fff8c 00000000 01753629 1623f280 00000000 ntdll!_RtlUserThreadStart+0x1b



We can discover that the crashing thread is trashed:

0:029> dx -r1 ((HRDLogbook!CLibBackgroundProcessingThread *)0x13924254)
((HRDLogbook!CLibBackgroundProcessingThread *)0x13924254)                 : 0x13924254 [Type: CLibBackgroundProcessingThread *]
    [+0x004] m_pWorkEvent     : 0x63316262 [Type: CEvent *]
    [+0x008] m_pExitEvent     : 0x69623b32 [Type: CEvent *]
    [+0x00c] m_nCycleTime     : 1448295791 [Type: int]
    [+0x010] m_bEndThread     : 1497580600 [Type: int]
    [+0x014] m_b2ndThread     : 2097152 [Type: int]
    [+0x018] m_hThread2       : 0x740073 [Type: void *]
    [+0x01c] m_cs             [Type: _RTL_CRITICAL_SECTION]
    [+0x034] m_csWeb          [Type: _RTL_CRITICAL_SECTION]
    [+0x04c] m_CritSect       [Type: CCriticalSection]
    [+0x06c] m_PktList        [Type: CObList]
    [+0x088] m_strTitle       [Type: ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > >]
    [+0x08c] m_bBlocked       : 5242967 [Type: int]
    [+0x090] m_pParent        : 0x200058 [Type: CWnd *]
    [+0x094] m_bCancelled     : 7471216 [Type: int]


but the thread that's blocked on the web request is fine:

0:029> dx -r1 ((HRDLogbook!CLibBackgroundProcessingThread *)0x42f544)
((HRDLogbook!CLibBackgroundProcessingThread *)0x42f544)                 : 0x42f544 [Type: CLibBackgroundProcessingThread *]
    [+0x004] m_pWorkEvent     : 0x13880ad8 [Type: CEvent *]
    [+0x008] m_pExitEvent     : 0x13880ae8 [Type: CEvent *]
    [+0x00c] m_nCycleTime     : -1 [Type: int]
    [+0x010] m_bEndThread     : 1 [Type: int]
    [+0x014] m_b2ndThread     : 1 [Type: int]
    [+0x018] m_hThread2       : 0xb50 [Type: void *]
    [+0x01c] m_cs             [Type: _RTL_CRITICAL_SECTION]
    [+0x034] m_csWeb          [Type: _RTL_CRITICAL_SECTION]
    [+0x04c] m_CritSect       [Type: CCriticalSection]
    [+0x06c] m_PktList        [Type: CObList]
    [+0x088] m_strTitle       : "Callsign Lookup" [Type: ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > >]
    [+0x08c] m_bBlocked       : 0 [Type: int]
    [+0x090] m_pParent        : 0x41f630 [Type: CWnd *]
    [+0x094] m_bCancelled     : 1 [Type: int]


The main thread we capture is awaiting the shutdown of the CLibBackgroundProcessingThread. That thread is blocked on the web request, so both are waiting. Another instance of thread exists, though, and that is the one that crashes. This pattern is visible in the HRDLogbook_20190423_211444.mdmp and HRDLogbook_20190423_205708.mdmp dumps, but not the HRDLogbook_20190423_210930.mdmp.

The HRDLogbook_20190423_210930.mdmp dump has a similar pattern not involving CLibBackgroundProcessingThread, but it does involve CThinThread -- and has the pattern of a call looking for work. Here's 210930's crashing thread:

0:025> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 169bf994 00efcb3c ffffffff 72dcd72d 1642b160 HRDLogbook!CSingleLock::Lock+0xf [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\mtex.cpp @ 108] 
01 169bf9cc 01003816 72dcd4ed 1642b160 01003780 HRDLogbook!CLibBackgroundProcessingThread::DoWork+0x5c [c:\hrd65\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 187] 
02 (Inline) -------- -------- -------- -------- HRDLogbook!CThinThread::Run+0x55 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 189] 
03 169bfa0c 01643680 16408f5c 72dcd4a9 00000000 HRDLogbook!CThinThread::Start+0x96 [c:\hrd65\logbook\hrdlogbook\thinthread.cpp @ 228] 
04 (Inline) -------- -------- -------- -------- HRDLogbook!invoke_thread_procedure+0xd [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 
05 169bfa48 74c5336a 1642b160 169bfa94 77139902 HRDLogbook!thread_start<unsigned int (__stdcall*)(void *)>+0x57 [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
06 169bfa54 77139902 1642b160 61afadb3 00000000 kernel32!BaseThreadInitThunk+0xe
07 169bfa94 771398d5 01643629 1642b160 00000000 ntdll!__RtlUserThreadStart+0x70
08 169bfaac 00000000 01643629 1642b160 00000000 ntdll!_RtlUserThreadStart+0x1b


At first blush, the common sisue among these crashes is the working thread code is still running, but the thread's representative C++ object has been deleted. The working thread ends up referencing member data and falls over.

The easiest way the thread might continue to run after the C++ object has been deleted is that the thread was requested to shut down, but it timed-out. The C++ object was deleted. When the thread returned from whatever was blocking it, it tried to access the C++ object and crashed.

This is a fundamental flaw in the design of CThinThread. Since CThinThread is going to delete itself when CloseDown() ends, it must wait indefinitely for the thread to actually exit before releasing the thread's memory.

PD9FER

2019-05-01 03:01

updater   ~0007898

I noticed in a 2nd remote, the same happens when you go to Tools > Configure > Callsign Lookup
Have the QRZ credentials set (I checked them and are valid)
Select the Test Tab
Enter a call and do the Test lookup.
The application goes non responding (blue circle)

Would a reinstall of Visual C++ runtime make sense?

K7ZCZ

2019-05-01 09:32

administrator   ~0007901

Reinstalling the VC++ Runtimes distribution doesn't make sense because the bug is in our code, and reinstalling the VC++ Runtimes won't fix it.

Issue History

Date Modified Username Field Change
2019-04-21 02:56 PD9FER New Issue
2019-04-23 12:35 K7ZCZ Note Added: 0007879
2019-04-23 12:59 PD9FER Note Added: 0007880
2019-04-23 14:31 K7ZCZ Note Added: 0007881
2019-04-23 14:31 K7ZCZ Status new => feedback
2019-04-23 14:55 PD9FER Note Added: 0007882
2019-04-23 14:55 PD9FER Status feedback => new
2019-04-23 16:34 K7ZCZ Note Added: 0007883
2019-04-24 03:44 PD9FER Note Added: 0007885
2019-04-24 09:05 K7ZCZ Note Added: 0007886
2019-04-24 14:43 K7ZCZ Note Added: 0007887
2019-04-24 15:25 K7ZCZ Note Added: 0007888
2019-05-01 03:01 PD9FER Note Added: 0007898
2019-05-01 09:32 K7ZCZ Note Added: 0007901