View Issue Details

IDProjectCategoryView StatusLast Update
0002875Ham Radio DeluxeBugpublic2018-09-11 13:18
Reporterk2ieAssigned ToK7ZCZ 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.886 
Summary0002875: Log QSO from WSJT-X to Logbook Using UDP Fwd Causes Minidump
DescriptionThis was first seen in build 881.
Steps To ReproduceLoad Rig Control, Logbook, and WSJT-X. Do not load JT Alert.
Configure Logbook to receive QSO forwarding notifications from WSJT-X on port 2333.
Log an FT8 QSO from WSJT-X.
Minidump and Logbook close occurs.

Additional InformationMinidump attached.
TagsNo tags attached.
Testing Beta Successful



2018-09-04 11:29


HRDLogbook_20180904_162627.mdmp (597,949 bytes)


2018-09-04 15:14

administrator   ~0006073

The call stack from the dump is given here:
0:013> .ecxr
eax=00000000 ebx=1a85afec ecx=00000008 edx=11c0d47c esi=11c0d4bc edi=00000982
eip=012bf196 esp=11c0d454 ebp=11c0d49c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
012bf196 8b08            mov     ecx,dword ptr [eax]  ds:002b:00000000=????????
0:013> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 11c0d49c 01977c77 1a85afec 00000982 b60f144b HRDLogbook!CXMLMgr::_LoadFromStringBSTR+0x136 [c:\ham radio\hrdcommon\xmlmgr.cpp @ 656] 
01 11c0d52c 01798675 15fb8d20 11c0e128 b60f1427 HRDLogbook!CUDPListenerBase::LSDCallback+0x87 [c:\ham radio\logbook\hrdlogbook\udplistenerbase.cpp @ 315] 
02 11c0e004 0197683f b60f2177 00000940 769ef750 HRDLogbook!CallsignLookup+0x1ec5 [c:\ham radio\logbook\hrdlogbook\backgroundprocessingthreadlookupcallsigns.cpp @ 581] 
03 11c0e804 01978f6f 11c0e830 11c0e844 b60f297f HRDLogbook!CUDPListenerBase::FixEmptyFields+0x6df [c:\ham radio\logbook\hrdlogbook\udplistenerbase.cpp @ 578] 
04 11c0e868 0197839e 11c0e9c0 b60f291f 01978070 HRDLogbook!CUDPN1MM9Listener::OnReceivedDatagram+0xbf [c:\ham radio\logbook\hrdlogbook\udpn1mm9listener.cpp @ 29] 
05 11c0f9d8 01978082 01978070 11c0f9f8 76998484 HRDLogbook!CUDPListenerBase::ReceiveLoop+0x16e [c:\ham radio\logbook\hrdlogbook\udplistenerbase.cpp @ 205] 
06 11c0f9e4 76998484 056de494 76998460 c16c23dd HRDLogbook!CUDPListenerBase::UDPReceiverWorker+0x12 [c:\ham radio\logbook\hrdlogbook\udplistenerbase.cpp @ 223] 
07 11c0f9f8 771d2fea 056de494 c0e7105d 00000000 kernel32!BaseThreadInitThunk+0x24
08 11c0fa40 771d2fba ffffffff 771eec14 00000000 ntdll!__RtlUserThreadStart+0x2f
09 11c0fa50 00000000 01978070 056de494 00000000 ntdll!_RtlUserThreadStart+0x1b


2018-09-04 15:37

administrator   ~0006074

At this point, a lookup has happened and it's coming back with results. The results are presented as an XML document. The callback handler thinks it has initialized a CXMLMgr instance in order to handle the document, but the initlaization of the XML parser has failed. The code involved does no error checking, so it proceeds to load the document against the NULL document pointer and crashes.

I'm guessing the cause of this is the failure to initialize COM on the UDP listener thread. I've added a call to do that, as well as some error logging code in this area. (It's sorely needed almost everywhere the CXMLMgr is used.)

I can check this fix in when the VSTS services come back online ...


2018-09-04 16:03

viewer   ~0006075

Thanks Mike B. I wonder if the minidump attached to 2876 is a similar or the same issue?


2018-09-05 10:11

administrator   ~0006079

fixed with this checkin


2018-09-05 19:39

administrator   ~0006090

The call stack provided here is the same as the call stack in 2876. It's the same underlying problem.


2018-09-07 02:53

viewer   ~0006103

FWIW. I have never had a crash when using WSJT-X with or without JTAlert.


2018-09-07 10:00

viewer   ~0006110

Test of WSJT-X with JT Alert and HRD Logbook Build 882:

All QSO forwarding options in Logbook off, log sent using HRD API.
QSO appears in Logbook: SUCCESS

Test of WTJX-X without JT Alert and HRD Logbook Build 882:

UDP Receive from WSJT-X turned on, option Merge selected.
QSO appears in Logbook: SUCCESS
Anomalies: Frequency RX is not populated even though transmit and receive offsets are different. It is populated when the record is sent via JT Alert.

Issue History

Date Modified Username Field Change
2018-09-04 11:29 k2ie New Issue
2018-09-04 11:29 k2ie File Added: HRDLogbook_20180904_162627.mdmp
2018-09-04 15:14 K7ZCZ Note Added: 0006073
2018-09-04 15:37 K7ZCZ Note Added: 0006074
2018-09-04 16:03 k2ie Note Added: 0006075
2018-09-05 10:11 K7ZCZ Assigned To => K7ZCZ
2018-09-05 10:11 K7ZCZ Status new => resolved
2018-09-05 10:11 K7ZCZ Resolution open => fixed
2018-09-05 10:11 K7ZCZ Testing => Not Started
2018-09-05 10:11 K7ZCZ Note Added: 0006079
2018-09-05 19:39 K7ZCZ Note Added: 0006090
2018-09-06 20:16 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2018-09-06 20:17 K7ZCZ Fixed in Version =>
2018-09-07 02:53 g3ucq Note Added: 0006103
2018-09-07 10:00 k2ie Note Added: 0006110
2018-09-07 16:15 WA9PIE Status resolved => closed
2018-09-07 16:15 WA9PIE Testing Not Started => Beta Successful
2018-09-11 13:15 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2018-09-11 13:18 WA9PIE Fixed in Version =>