View Issue Details

IDProjectCategoryView StatusLast Update
0003178Ham Radio DeluxeBugpublic2019-02-24 15:13
Reporterg3ucqAssigned ToK7ZCZ 
Status closedResolutionfixed 
PlatformPCOSWindowsOS Version10 64 bit Home
Product Version 
Target VersionFixed in Version6.5.0.196 
Summary0003178: JTAlert QSO forwarding causes a mini dump to be created
DescriptionThis from user N8FRI.
He reports that since returning to using JTAlert , instead of just WSJT-X, he gets mini dumps created as the attached file.
Steps To ReproduceFrom N8FRI.
As I stated, I used JTAlert to log for 2years with no problem. Switching to WSJT-X to try it out. Last week I decided to go back to JTAlert for logging because of the log update feature.

My sequence of events are;
1. load HRD with HRD logbook
2. load JTAlert with auto start of WSJT-X
3. Make contact
4. When auto log box appears (with all of the correct exchange), I hit "log contact".
5. JTAlert log confirmation box then pops up and disappears after 3 seconds.
6. Bring up HRD log (running in background).
7. All information from qso is correctly entered, but the minidump box is displayed.
8. HRD log closes.

 JTAlert site claims it is a HRD problem.
I went back to logging with WSJT-X and everything works fine again. I would really like to get JTAlert logging started again. Any ideas?

Mike N8FRI
TagsNo tags attached.
Testing Beta Successful



2019-02-15 12:12

viewer (115,042 bytes)


2019-02-16 10:25

administrator   ~0007405

This bug is a pretty good example of the fragility of the code in this product.

Different parts of the Logbook application exchange data by writing files, then sending a message with that file name. It's hard to understand why this architecture was chosen over any other in-memory mechanism, which would be more robust and faster. But that's the way it works.

The files are formatted as XML. There's a bit of shared code that handles creating and reading XML documents.

When JTALERT sends a UDP datagram that a contact was made, the Logbook has a listener that reads that data and parses it. The parsing doesn't seem to be quite perfect; it seems to be tripping over the ADIF "<EOH>" tag.

Here's the callstack for the crash:

0:024> kp
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  
00 1559ea00 010f6207 HRDLogbook!CXMLMgr::AddAttribute(struct IXMLDOMElement * pElement = 0x0562bf28, class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * strName = 0x1559ea68 "EOH><CALL", class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * strInput = 0x1559ea74 "W0ZXR")+0x113 [c:\hrd65\hrdcommon\xmlmgr.cpp @ 1940] 
01 1559eabc 0112adb1 HRDLogbook!CQSOInterchange::FieldsValuesToFile(class CStringArray * astrFields = 0x1559eb2c, class CStringArray * astrValues = 0x1559eb18, class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > * strFilename = 0x1559eafc "C:\Users\Mike\AppData\Local\Temp\HRD_QSO_5C65FB3A_00000000.txt")+0x3b7 [c:\hrd65\logbook\hrdlogbook\qsointerchange.cpp @ 69] 
02 1559eaf4 0112b7b4 HRDLogbook!CUDPListenerBase::AddADIFToLogbook(class CWnd * pWndOwner = 0x078331e8 {hWnd={...}}, class CStringArray * astrFields = 0x1559eb2c, class CStringArray * astrValues = 0x1559eb18)+0xb1 [c:\hrd65\logbook\hrdlogbook\udplistenerbase.cpp @ 739] 
03 1559eb54 0112907c HRDLogbook!CUDPN1MM9Listener::OnReceivedDatagram(char * pstrBuffer = <Value unavailable error>)+0x1b4 [c:\hrd65\logbook\hrdlogbook\udpn1mm9listener.cpp @ 62] 
04 1559fcb4 0112918c HRDLogbook!CUDPListenerBase::ReceiveLoop(void)+0x17c [c:\hrd65\logbook\hrdlogbook\udplistenerbase.cpp @ 216] 
05 1559fcc0 75588484 HRDLogbook!CUDPListenerBase::UDPReceiverWorker(void * workContext = 0x078333d0)+0x1c [c:\hrd65\logbook\hrdlogbook\udplistenerbase.cpp @ 237] 
06 1559fcd4 776a41c8 kernel32!BaseThreadInitThunk+0x24
07 1559fd1c 776a4198 ntdll!__RtlUserThreadStart+0x2f
08 1559fd2c 00000000 ntdll!_RtlUserThreadStart+0x1b

We can see that the code in the logbook is trying to write an XML file with the data received from JTALERT. In response, it's trying to write an attirbute into a part of the XML document. The attribute will be named "EOH><CALL" and the value of the attribtue would be "W0ZXR".

Of course, the name of the attribute should be "CALL"; something has gone wrong with the parsing, so the "EOH><" text is there but shouldn't be. In XML, an attribute can have certain reserved characters in it -- like <brackets>, so the XML operation fails. There's no error checking there, so it just crashes rather than doing something sensible.

Then, this bug is caused by the failure to check error returns from API calls when writing XML docs (that we don't need) when sending messages to ourselves (which we shouldn't be doing).


2019-02-16 11:03

administrator   ~0007406

I've made a fix in the XML code to return an error (and not crash) if an attribute couldn't be added successfully.

The QSO Forwarder code will log a message to the Logfile window if this happens while handling a QSO report from another program.

I'm not able to specifically reproduce the reported issue because I can't find a way to make JTAlert send a header with its report. There's no "<EOH>" in the message that I receive, then, so I can't test my fix to the ADIF parsing code. However, with my fix the code does correctly and actively handle "<EOR>". It didn't do so previously, but got away with it because EOR indicates the end of the record -- and no useful data followed so there wasn't anything gummed-up by the bad state of the parser.


2019-02-16 11:04

administrator   ~0007407

Fixed with this checkin

As usual, John, thanks for the solid report


2019-02-20 03:14

viewer   ~0007453

Glad it helped.


2019-02-21 09:41

administrator   ~0007475

Validated by G3UCQ

Issue History

Date Modified Username Field Change
2019-02-15 12:12 g3ucq New Issue
2019-02-15 12:12 g3ucq File Added:
2019-02-16 10:25 K7ZCZ Note Added: 0007405
2019-02-16 11:03 K7ZCZ Note Added: 0007406
2019-02-16 11:04 K7ZCZ Assigned To => K7ZCZ
2019-02-16 11:04 K7ZCZ Status new => resolved
2019-02-16 11:04 K7ZCZ Resolution open => fixed
2019-02-16 11:04 K7ZCZ Note Added: 0007407
2019-02-17 19:55 WA9PIE Project 1 - Backlog => 3 - Current Dev List
2019-02-19 19:04 K7ZCZ Fixed in Version =>
2019-02-20 03:14 g3ucq Note Added: 0007453
2019-02-21 09:41 WA9PIE Status resolved => closed
2019-02-21 09:41 WA9PIE Testing Not Started => Beta Successful
2019-02-21 09:41 WA9PIE Note Added: 0007475
2019-02-24 14:36 WA9PIE Fixed in Version =>
2019-02-24 15:13 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe