View Issue Details

IDProjectCategoryView StatusLast Update
0002199Ham Radio DeluxeBugpublic2018-06-01 23:21
Assigned ToK7ZCZ 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.840 
Summary0002199: HRD Logbook stops responding
DescriptionEntered a QSO into the Logbook ALE window and the Logbook stopped crashed.
Steps To ReproduceOpen HRD Rig Control, Logbook and DM780 by default.
Entered one QSO into the ALE window. I clicked on the Lookup button and the Logbook stopped responding.
This problem seemed to have been fixed.
Additional InformationMinidump attached.
TagsNo tags attached.
Sub-ModuleALE Window
Testing Beta Successful


has duplicate 0002253 closedK7ZCZ HRD Logbook stops responding 
related to 0002596 closedK7ZCZ crash in Logbook with minidump 



2017-08-13 03:01


HRDLogbook.dmp (179,409 bytes)


2017-08-17 22:53

manager   ~0004015

Here's the call stack from the minidump:

     00000004() Unknown
     [Frames below may be incorrect and/or missing]
     HRDLogbook.exe!_AfxDispatchCmdMsg(CCmdTarget * pTarget, unsigned int nID, int nCode, void (void) * pfn, void * pExtra, unsigned int nSig, AFX_CMDHANDLERINFO * pHandlerInfo) Line 78 C++
     HRDLogbook.exe!CCmdTarget::OnCmdMsg(unsigned int nID=20373, int nCode=2007354384, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 373 C++
     HRDLogbook.exe!CPropertySheet::OnCmdMsg(unsigned int nID=20373, int nCode=0, void * pExtra=0x00000000, AFX_CMDHANDLERINFO * pHandlerInfo=0x00000000) Line 816 C++
> HRDLogbook.exe!CWnd::OnCommand(unsigned int wParam=20373, long lParam=0) Line 2784 C++
     HRDLogbook.exe!CWnd::OnWndMsg(unsigned int message=273, unsigned int wParam=20373, long lParam=0, long * pResult=0x0018ec08) Line 2108 C++
     HRDLogbook.exe!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message=273, unsigned int wParam=20373, long lParam=0, long * pResult=0x0018ec08) Line 194 C++
     HRDLogbook.exe!CWnd::WindowProc(unsigned int message=273, unsigned int wParam=20373, long lParam=0) Line 2094 C++
     HRDLogbook.exe!AfxCallWndProc(CWnd * pWnd=0x1ac92770, HWND__ * hWnd=0x00040e08, unsigned int nMsg=273, unsigned int wParam=20373, long lParam=0) Line 285 C++
     HRDLogbook.exe!AfxWndProc(HWND__ * hWnd=0x00040e08, unsigned int nMsg=273, unsigned int wParam=20373, long lParam=0) Line 434 C++
     [External Code]
     HRDLogbook.exe!CXTPHookManager::HookWndProc(HWND__ * hWnd=0x00cb547f, unsigned int message=273, unsigned int wParam=20373, long lParam=0) Line 267 C++
     [External Code]
     HRDLogbook.exe!CWnd::SendChildNotifyLastMsg(long * pResult=0x00cb8a31) Line 3378 C++
     HRDLogbook.exe!CWnd::ReflectLastMsg(HWND__ * hWndChild=0x00000000, long * pResult=0x00000000) Line 3416 C++


2017-08-17 22:53

manager   ~0004016

The CWnd::OnWndMsg() call means that something was sending messages to a window. The parameters to that call indicate the message is WM_COMMAND (273), and it carries the wParam 20373. Correctly, MFC ends up calling CWnd::OnCommand to process that message by offering it to the CCmdTraget class and be dispatched. The ID given is 20373, which has the symbol IDC_RESET in the code.

We can't see what the specific window is because that information isn't in the minidump or the call stack. We can see it's a CXTPDialogBase<CXTPResizeDialog>, which tells us it's a resizeable dialog, though. When the call is made, we lose insight into the stack but it looks like we end up calling into a NULL pointer because the window in question has been destroyed. It's not too common for WM_COMMAND message handling to meet such a fate because the message is normally sent in user interaction with the control; how could the control disappear from MFC's handle map when the user is still interacting with it?

There's about a dozen controls in the Logbook application with the IDC_RESET ID. In filtering through them, we can eventually find one that matches the reported scenario at the time the crash was encountered; the OnOK handler for CLogbookFull ends up calling SendMessage(WM_COMMAND, IDC_RESET).

CLogbookFull is what people commonly call "the ALE". Its IDOK button is actually the "Add" button (with the keyboard shortcut of F7).

Presumably, then, the SendMEssage call in OnOK is sending the message to the REset button, but the reset button is already destroyed and its owning window kicked out of the MFC message map. Unfortunately, the call stack only shows C++ calls and not Windows message flow; there's no way to dump windows message flow. That's why this analysis is neccessary to find the calling site, and why passing windows messages for application flow is not a strong architecture.

A common problem in the HRD applications is the invocation of a message pump during the handling of other messages. Pumping messages outside of MFC is dangerous because MFC assumes it owns the message pump. The pumped messages essentially disrupt the order of expected events in the application. In this case, the OnOK handler expects to interact with windows because, even though the OK button is the default pushbutton for this application and will intrinsically end the dialog box, the handling of OnOK hasn't yet completed and the dialog box is still viable.

However, before the call to send WM_COMMAND to IDC_RESET, the OnOK handler pumps messages. This means that it's possible (and even likely) that the message pump in the OnOK handler shows WM_DESTROY or WM_CLOSE messages to MFC, inappropriately disconnecting the target window from the internal MFC window map.

The tempting first fix is to remove the message pump; it's not completely apparent why it's necessary. This fix isn't indicated because the message pump alters the order of processing, and the application might have come to expect at least some part of the altered message processing order and now requires that ordering.

Note that the path I'm following through the OnOK handler involving the message pump assumes that automatic callsign lookup is turned on and that a name wasn't entered in this QSO contact. Rather than any sensible synchornization mechansim, the CallsignLookup method in the CLogbookFull class uses a boolean member variable and a couple of message loops to try to signal progress while spending time performing a lookup.

If callsign lookup or a name was entered, then my diagnosis might not be correct -- but I can't find any other places where the ALE window pumps its own messages and could conceivably defeat the message processing in MFC, leading to a crash of this shape.


2017-08-17 23:20

manager   ~0004019

The auxillary message pump is entered in this conditional:

    if( sName.IsEmpty() && m_options.UseAutoLookup() && !m_bModify )

UseAutoLookup is on by default, and adding a QSO means m_bModify is FALSE (meaning we're NOT modifying an exisiting record). Thus, the assumed flow mentioned above is ceratinly the case where we cause trouble.

The choice to use SendMessage() to invoke IDC_RESET is very curious because the action simply invokes the OnReset() handler. OnReset() is just a member function, and could be called directly. Of course, in this scenario, it would probably just crash as well because it touches all/most of the control windows in the ALE. But certainly the message passing approach in this case is completely unwarranted.


2017-08-21 08:45

viewer   ~0004066

Another crash after entering just one qso.
Minidump attached

HRDLogbook-2.dmp (191,810 bytes)


2017-09-12 22:15

manager   ~0004180

HRDLogbook-2.dmp is from build 780 of the product.

Opening that dump in windbg gives a bit better stack trace. The previous stack trace is missing a frame, and the fuller stack trace (and attached information) shows that the previous assessment of failing to execute the OnReset() handler in CLogbookFull is incorrect.

Here's the first few frames of the better stack from windbg:

0:000> ~kp
 # ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 0018e444 0153356a 0x4
01 0018e784 00fabb0e HRDLogbook!CLogbookFull::OnReset(void)+0x73a [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 6240]
02 0018e794 00fab947 HRDLogbook!_AfxDispatchCmdMsg(class CCmdTarget * pTarget = 0x1d3b4a50, unsigned int nID = 0x4f95, int nCode = 0n0, <function> * pfn = 0x01532e30, void * pExtra = 0x00000000, unsigned int nSig = 0x3a, struct AFX_CMDHANDLERINFO * pHandlerInfo = 0x00000000)+0x42 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 78]
03 0018e7c4 00fb0564 HRDLogbook!CCmdTarget::OnCmdMsg(unsigned int nID = 0x4f95, int nCode = 0n0, void * pExtra = 0x00000000, struct AFX_CMDHANDLERINFO * pHandlerInfo = 0x00000000)+0x120 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 373]
04 0018e7e8 00fa727c HRDLogbook!CDialog::OnCmdMsg(unsigned int nID = 0x4f95, int nCode = 0n0, void * pExtra = 0x00000000, struct AFX_CMDHANDLERINFO * pHandlerInfo = 0x00000000)+0x1b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 85]
05 0018e838 00fa7e69 HRDLogbook!CWnd::OnCommand(unsigned int wParam = 0x4f95, long lParam = 0n0)+0x89 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2784]
06 0018e8f0 00f7d486 HRDLogbook!CWnd::OnWndMsg(unsigned int message = 0x111, unsigned int wParam = 0x4f95, long lParam = 0n0, long * pResult = 0x0018e928)+0x3c [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2108]
07 0018e90c 00fa96cd HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg(unsigned int message = 0x111, unsigned int wParam = 0x4f95, long lParam = 0n0, long * pResult = 0x0018e928)+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194]
08 0018e92c 00fa4d4e HRDLogbook!CWnd::WindowProc(unsigned int message = 0x111, unsigned int wParam = 0x4f95, long lParam = 0n0)+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094]
09 0018e99c 00fa5503 HRDLogbook!AfxCallWndProc(class CWnd * pWnd = 0x1d3b4a50, struct HWND__ * hWnd = 0x00010e8c, unsigned int nMsg = 0x111, unsigned int wParam = 0x4f95, long lParam = 0n0)+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285]

Here, we see that OnReset() is being reached, and we're actually executing quite a bit of the function. We end up in a loop that calls the Reset() methods of each of the pages within the ALE.

If we dump some assembly at the crash site, we find this code implementing the loop:

0:000> u
HRDLogbook!CLogbookFull::OnReset+0x73a [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 6240]:
0153356a 8d7610 lea esi,[esi+10h]
0153356d 4b dec ebx
0153356e 75f0 jne HRDLogbook!CLogbookFull::OnReset+0x730 (01533560)
01533570 53 push ebx
01533571 8bcf mov ecx,edi
01533573 e8935ea7ff call HRDLogbook!CWnd::UpdateData (00fa940b)
01533578 6898c47501 push offset HRDLogbook!`string' (0175c498)
0153357d 8d8f70010000 lea ecx,[edi+170h]

We can see that the loop ends at 153356e, where it branches backward to 01533560. Let's disassemble from that point to get a bit more context:

0:000> u 01533560
HRDLogbook!CLogbookFull::OnReset+0x730 [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 6240]:
01533560 8b0e mov ecx,dword ptr [esi]
01533562 8b01 mov eax,dword ptr [ecx]
01533564 ff9088010000 call dword ptr [eax+188h]
0153356a 8d7610 lea esi,[esi+10h]
0153356d 4b dec ebx
0153356e 75f0 jne HRDLogbook!CLogbookFull::OnReset+0x730 (01533560)
01533570 53 push ebx
01533571 8bcf mov ecx,edi

Here, we see that we're chasing some pointers into a structure to find the address that's eventually called.

Switching stack frames:

0:000> dx Debugger.Sessions[0].Processes[7704].Threads[9276].Stack.Frames[1].SwitchTo();dv /t /v
@ecx class CLogbookFull * this = 0x1d3c9bc0
0018e484 struct CLogbookFull::OnReset::__l63::<unnamed-type-aTabs> [15] aTabs = struct CLogbookFull::OnReset::__l63::<unnamed-type-aTabs> [15]
0018e47c class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > > strClass = class ATL::CStringT<wchar_t,StrTraitMFC<wchar_t,ATL::ChTraitsCRT<wchar_t> > >
0018e574 wchar_t [256] szClass = wchar_t [256] "Edit"
0018e460 struct tagMSG msg = {msg=0x62f1700 wp=0x0 lp=0x28}

reveals that the aTabs array is available in the dump. Looking at the registers avaialble in the frame:

0:000> .frame /r 1
01 0018e784 00fabb0e HRDLogbook!CLogbookFull::OnReset+0x73a [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 6240]
eax=016ab930 ebx=00000003 ecx=1d3c9bc0 edx=00000064 esi=0018e544 edi=1d3b4a50
eip=0153356a esp=0018e44c ebp=0018e784 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206

we find that the ecx value is "1d3c9bc0". This should be the "this" pointer of the object we're calling into.

Sure enough dumping the aTabs array shows that aTabs[12] has a pDialog equal to 1D3C9BC0, like this:

0:000> dx -r2 ((HRDLogbook!CLogbookFull::OnReset::__l63::<unnamed-type-aTabs> (*)[15])0x18e484)
((HRDLogbook!CLogbookFull::OnReset::__l63::<unnamed-type-aTabs> (*)[15])0x18e484) : 0x18e484 [Type: CLogbookFull::OnReset::__l63::<unnamed-type-aTabs> (*)[15]]
    [0] [Type: CLogbookFull::OnReset::__l63::<unnamed-type-aTabs>]
        [+0x000] pDialog : 0x1d3c8ff4 [Type: CDialogWndBase *]
        [+0x004] nIDD : 20020 [Type: int]
        [+0x008] lpszTitle : 0x1762bf0 : "Logbook" [Type: wchar_t *]
        [+0x00c] bAdjustTab : 1 [Type: int]
    [1] [Type: CLogbookFull::OnReset::__l63::<unnamed-type-aTabs>]
        [+0x000] pDialog : 0x1d3ca4d8 [Type: CDialogWndBase *]
        [+0x004] nIDD : 20061 [Type: int]
        [+0x008] lpszTitle : 0x1777864 : "Worked" [Type: wchar_t *]
        [+0x00c] bAdjustTab : 1 [Type: int]
    [12] [Type: CLogbookFull::OnReset::__l63::<unnamed-type-aTabs>]
        [+0x000] pDialog : 0x1d3c9bc0 [Type: CDialogWndBase *]
        [+0x004] nIDD : 20025 [Type: int]
        [+0x008] lpszTitle : 0x179a0e8 : "QSL" [Type: wchar_t *]
        [+0x00c] bAdjustTab : 1 [Type: int]

At this point, we know that the OnReset() method implementation should be called, but it isn't. The calling code is this opcode:

01533564 ff9088010000 call dword ptr [eax+188h]

If we see what it dereferences, we quickly discover an interesting symptom:

0:000> ? eax+188
Evaluate expression: 23771832 = 016abab8

0:000> dd 16abab8
016abab8 00000004 00000001 016ab69c 00000000
016abac8 00000001 016ab6c4 00000000 00000001
016abad8 016ab6ac 00000010 00000001 00000000

The v-table for the class contains 0x0000004 where it should contain a pointer to the virtual function for the CLogbookWndQSL::Reset() implementation.

Did the v-table get overwritten?

Worse, this analysis doesn't fit the symptoms. One user reports an occasional crash, but I'm unable to reproduce the problem altogether.


2018-03-16 06:08

viewer   ~0004493

No problems with .796 so far but this has always been a random occurrence for me.
The only common factor, for me, is the Logbook stops responding when the ALE is in use.


2018-04-05 10:56

viewer   ~0004701

Another Logbook crash after entering a QSO. It's a while since this has happened and is so random.
Minidump added (118,610 bytes)


2018-04-05 17:56

manager   ~0004708

The minidump provided in April 5 is the same memory corruption issue previously reported in this issue.

There's no enough information in the minidump to find a root cause, so the most hopeful vector of attack is to collect detailed repro information and try to cause the problem under the debugger.


2018-04-07 02:59

viewer   ~0004737

Entered 10 QSOs without a problem so fingers crossed.


2018-04-07 05:30

viewer   ~0004742

I spoke too soon. First QSO entered after a fresh reboot and Logbook crashed. (133,443 bytes)


2018-04-07 08:52

manager   ~0004744

G3UCQ, at this point, I'm looking for a detailed repro of what you're doing. The minidumps contain the same information again and again, so they're not going to help me make progress.

I'm sure what you're doing seems obvious to you. It's your computer, and it's your pattern of working; but I'm not there, and I can't see what you're doing. Since I need to reproduce this crash in order to fix it, I need to know how you're making it happen. HRD is a big program with lots of modes. Things that might influence the pattern include, but aren't limited to:

1) How do you open the ALE to enter the QSO? There are at least four ways to do so.
2) What other applications are active when you're adding the QSO? What are they doing?
3) Do you have the DX cluster window connected? Is it active? Does it have a filter?
4) Which tabs do you access or use before saving the QSO? Which data do you enter?
5) Which fields do you enter or modify in the ALE's main window?
6) Which buttons or controls do you use in the ALE when editing the QSO?
7) Do you have frequency or mode tracking features turned on? Is a radio connected, and is Rig Control running?


2018-04-07 10:31

viewer   ~0004746

OK Mike. I will try.
3B7A was a good signal on 17m cw so I turned on my IC-7610 and amplifier.
I then loaded HRD and the Logbook (that is all). Tuned to 3B7A and called him for about 10/15 minutes when I made the QSO.
I clicked on the Logbook ADD button and entered 3B7A, clicked Lookup which populated the boxes and clicked Update.
It was then that the Logbook stopped responding. On re-loading Logbook the QSO had been entered.
I rarely, if ever have other windows open unless I am using data modes and then DM780 of course.
It cannot be RF as I am not transmitting when I add a QSO.
The problem always involves the ALE, which, for me, takes some time to open. QSOs fed from JTAlert NEVER cause a crash.


2018-04-07 10:36

viewer   ~0004747

Sorry. Should have answered your questions more thoroughly.
1) Sometimes the ADD button, sometimes r-click on a cluster spot.
2) No other applications.
3) Yes the Cluster is open and active. No filters, just the band selected I am using.
4) No tabs selected.
5) The call sign and then press Lookup followed by Update.
6) Just the Lookup usually.
7) Yes frequency and mode tracking are on from Rig Control from my IC-7610.


2018-04-09 14:58

viewer   ~0004783

Using v806 I had another Logbook crash.
This is the sequence of events.
I had previously uninstalled v806, which is something I rarely do, and manually deleted the HRDLLC folder .
I reinstalled v806 and immediately noticed that the Logbook ALE was opening faster than in the past.
I then made a few QSOs and logged them without problems.
Later I noticed that the ALE was getting slower to open i.e from about 2 seconds earlier to 5-10 seconds as in the past.
I made another QSO, the ALE was slow to open. I entered the QSO, closed the ALE and got the minidump message.
Running was Rig Control, Logbook with the Cluster and DM780. Nothing else. HTH (134,400 bytes)


2018-04-10 03:02


G3UCQ_2018-04-10 (897,486 bytes)


2018-04-10 03:02

viewer   ~0004791

In case this may throw some light on what is happening I have recorded my screen.
Only Rig Control and the Logbook are open.
Bring up Task Manager
Rig Control and Logbook are displayed at the top of the window.
Go to the Antimalware Service Executable.
Select Endtask. I get an OK or Cancel box which is not recorded.
I click OK and the Logbook and Rig Control disappear from the top.
Close Task Manager and reopen it (black screen sequence) and Logbook and Rig Control are back at the top of the Task Manager screen.
Repeat the process and the same thing happens.


2018-04-10 08:48

manager   ~0004792

I'm not sure I understand what the point of your video is, but using Task Manager to kill arbitrary processes on your system isn't something we support.


2018-04-10 09:14

viewer   ~0004793

You told me in a post in the forum that a video to see the sequence of events would be useful. Obviously not.
Re. Task Manager. I was just trying to suggest that the Antimalware MAY have something to do with the way the Logbook behaves.
It seems that a fix for the Logbook crashing is no closer.


2018-04-10 09:52

manager   ~0004794

Your video shows Task Manager being used to kill a system service. This is a very dangerous action which can corrupt data on your computer, depending on which service you decide to kill. It's not a common scenario. If it causes problems on your computer, it's not something I will write code to fix. Purposefully undermining the stability of your system by killing arbitrary services with Task Manager isn't an experiment that teaches us anything useful. System unstability after forcing certain services to abnormally terminate is completely expected.

If you have a video of, or specific repro steps that demonstrate the crashes you've been experiencing when editing with the ALE, those would be useful because they show a problem intrinsic to HRD itself. I'm hoping that information would be useful because I'm completely unable to reproduce the crashes you describe. With the dumps you've provided, I can see the effect of the crashes you're having, but I can't quite determine their cause. At this point, the only hope I have to fixing the problem you're experiencing is finding a way to reproduce it reliably on my own machine; or catching a dump that happens to have some better clues in it.

I'd be thrilled to receive a video of your use of the ALE that led to a crash.


2018-04-10 10:35

viewer   ~0004795

As I was closing the Windows Defender Antimalware service I did not think that would have a detrimental effect on my System. I do have Kaspersky AV also. I would never close any other processes.
I will certainly provide videos when I can but the crashes are so random I cannot have the screen capture video running all the time.


2018-04-10 11:13

manager   ~0004796

The HRDLogbook_20180409_194506.mdmp dump shows that OnOK is calling OnReset(). I think that previous callstacks let me reason this out, but this is the first time I've had a complete callstack through the Windows ::SendMessage() call that chains the two calls together.

Also, G3UCQ, the nature of this crash demands "full" dumps. You've begun sending small dumps; otherwise, I don't see enough of the content of memory to have any chance of what's going on. Notes about setting the dump file size are in the forum at this post:

0:000> .ecxr
*** WARNING: Unable to verify checksum for HRDLogbook.exe
eax=00a81690 ebx=00000003 ecx=21156eb8 edx=00000000 esi=01bbe354 edi=21141d48
eip=00000004 esp=01bbe258 ebp=01bbe594 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206
00000004 ?? ???
0:000> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 01bbe254 0090a0aa b8118657 00000111 00000000 0x4
01 01bbe594 00364dfe 00000000 21141d48 01bbe5d4 HRDLogbook!CLogbookFull::OnReset+0x73a [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 6213]
02 01bbe5a4 00364c37 21141d48 00004f95 00000000 HRDLogbook!_AfxDispatchCmdMsg+0x42 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 78]
03 01bbe5d4 0036988a 00004f95 00b9161c 00000000 HRDLogbook!CCmdTarget::OnCmdMsg+0x120 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 373]
04 01bbe5f8 0036056a 00004f95 00000000 00000000 HRDLogbook!CDialog::OnCmdMsg+0x1b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 85]
05 01bbe648 00361158 00004f95 00000000 b81184c3 HRDLogbook!CWnd::OnCommand+0x89 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2784]
06 01bbe700 0032d896 00000111 00004f95 00000000 HRDLogbook!CWnd::OnWndMsg+0x3c [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2108]
07 01bbe71c 003629bc 00000111 00004f95 00000000 HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194]
08 01bbe73c 0035e3ae 00000111 00004f95 00000000 HRDLogbook!CWnd::WindowProc+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094]
09 01bbe7ac 0035eb63 21141d48 000c0ce0 00000111 HRDLogbook!AfxCallWndProc+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285]
0a 01bbe7cc 77b6e0bb 000c0ce0 00000111 00004f95 HRDLogbook!AfxWndProc+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434]
0b 01bbe7f8 77b78849 0035eb2f 000c0ce0 00000111 user32!_InternalCallWinProc+0x2b
0c 01bbe81c 77b7b145 00000111 00004f95 00000000 user32!InternalCallWinProc+0x20
0d 01bbe8ec 77b7833a 0035eb2f 00000000 00000111 user32!UserCallWinProcCheckWow+0x1be
0e 01bbe930 77b5fbab 00000111 00004f95 00000000 user32!CallWindowProcAorW+0xd4
0f 01bbe948 005e6bac 0035eb2f 000c0ce0 00000111 user32!CallWindowProcW+0x1b
10 01bbe990 77b6e0bb 0035eb2f 00000111 00004f95 HRDLogbook!CXTPHookManager::HookWndProc+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267]
11 01bbe9bc 77b78849 005e6b00 000c0ce0 00000111 user32!_InternalCallWinProc+0x2b
12 01bbe9e0 77b7b145 00000111 00004f95 00000000 user32!InternalCallWinProc+0x20
13 01bbeab0 77b68503 005e6b00 00000000 00000111 user32!UserCallWinProcCheckWow+0x1be
14 01bbeb18 77b68aa0 049b62e0 00000000 00000111 user32!DispatchClientMessage+0x1b3
15 01bbeb60 77db0bcd 01bbeb7c 00000020 01bbecd4 user32!__fnDWORD+0x50
16 01bbeb98 77d22a4c 77b7a9fd 000c0ce0 00000111 ntdll!KiUserCallbackDispatcher+0x4d
17 01bbeb9c 77b7a9fd 000c0ce0 00000111 00004f95 win32u!NtUserMessageCall+0xc
18 01bbec08 77b5b95b 049b62e0 00000000 00000000 user32!SendMessageWorker+0x860
19 01bbec34 009108f7 000c0ce0 00000111 00004f95 user32!SendMessageW+0x5b
1a 01bbece4 00364dfe 00000000 21141d48 01bbed24 HRDLogbook!CLogbookFull::OnOK+0x6e7 [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 4236]
1b 01bbecf4 00364c37 21141d48 00000001 00000000 HRDLogbook!_AfxDispatchCmdMsg+0x42 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 78]
1c 01bbed24 0036988a 00000001 00a834d8 00000000 HRDLogbook!CCmdTarget::OnCmdMsg+0x120 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 373]
1d 01bbed48 0036056a 00000001 00000000 00000000 HRDLogbook!CDialog::OnCmdMsg+0x1b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 85]
1e 01bbed98 00361158 00000001 00051132 b8118d93 HRDLogbook!CWnd::OnCommand+0x89 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2784]
1f 01bbee50 0032d896 00000111 00000001 00051132 HRDLogbook!CWnd::OnWndMsg+0x3c [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2108]
20 01bbee6c 003629bc 00000111 00000001 00051132 HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194]
21 01bbee8c 0035e3ae 00000111 00000001 00051132 HRDLogbook!CWnd::WindowProc+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094]
22 01bbeefc 0035eb63 21141d48 000c0ce0 00000111 HRDLogbook!AfxCallWndProc+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285]
23 01bbef1c 77b6e0bb 000c0ce0 00000111 00000001 HRDLogbook!AfxWndProc+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434]
24 01bbef48 77b78849 0035eb2f 000c0ce0 00000111 user32!_InternalCallWinProc+0x2b
25 01bbef6c 77b7b145 00000111 00000001 00051132 user32!InternalCallWinProc+0x20
26 01bbf03c 77b7833a 0035eb2f 00000000 00000111 user32!UserCallWinProcCheckWow+0x1be
27 01bbf080 77b5fbab 00000111 00000001 00051132 user32!CallWindowProcAorW+0xd4
28 01bbf098 005e6bac 0035eb2f 000c0ce0 00000111 user32!CallWindowProcW+0x1b
29 01bbf0e0 77b6e0bb 0035eb2f 00000111 00000001 HRDLogbook!CXTPHookManager::HookWndProc+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267]
2a 01bbf10c 77b78849 005e6b00 000c0ce0 00000111 user32!_InternalCallWinProc+0x2b
2b 01bbf130 77b7b145 00000111 00000001 00051132 user32!InternalCallWinProc+0x20
2c 01bbf200 77b68503 005e6b00 00000000 00000111 user32!UserCallWinProcCheckWow+0x1be
2d 01bbf268 77b68aa0 049b62e0 00000000 00000111 user32!DispatchClientMessage+0x1b3
2e 01bbf2b0 77db0bcd 01bbf2cc 00000020 01bbf55c user32!__fnDWORD+0x50
2f 01bbf2e8 77d22a4c 77b7a9fd 000c0ce0 00000111 ntdll!KiUserCallbackDispatcher+0x4d
30 01bbf2ec 77b7a9fd 000c0ce0 00000111 00000001 win32u!NtUserMessageCall+0xc
31 01bbf358 77b5b95b 049b62e0 00000000 00051132 user32!SendMessageWorker+0x860
32 01bbf380 74506934 000c0ce0 00000111 00000001 user32!SendMessageW+0x5b
33 01bbf3a0 745068f9 201cf940 00000202 00000000 comctl32!Button_NotifyParent+0x39
34 01bbf3b8 7451c14b 7451b890 00051132 00000000 comctl32!Button_ReleaseCapture+0x9b
35 01bbf44c 77b6e0bb 00051132 00000202 00000000 comctl32!Button_WndProc+0x8bb
36 01bbf478 77b78849 7451b890 00051132 00000202 user32!_InternalCallWinProc+0x2b
37 01bbf49c 77b7b145 00000202 00000000 00070030 user32!InternalCallWinProc+0x20
38 01bbf56c 77b7833a 7451b890 00000000 00000202 user32!UserCallWinProcCheckWow+0x1be
39 01bbf5b0 77b5fbab 00000202 00000000 00070030 user32!CallWindowProcAorW+0xd4
3a 01bbf5c8 0035f949 7451b890 00051132 00000202 user32!CallWindowProcW+0x1b
3b 01bbf5e8 003629d3 00000202 00000000 00070030 HRDLogbook!CWnd::DefWindowProcW+0x46 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 1116]
3c 01bbf604 0035e3ae 00000202 00000000 00070030 HRDLogbook!CWnd::WindowProc+0x39 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2095]
3d 01bbf674 0035eb63 21142be4 00051132 00000202 HRDLogbook!AfxCallWndProc+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285]
3e 01bbf694 77b6e0bb 00051132 00000202 00000000 HRDLogbook!AfxWndProc+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434]
3f 01bbf6c0 77b78849 0035eb2f 00051132 00000202 user32!_InternalCallWinProc+0x2b
40 01bbf6e4 77b7b145 00000202 00000000 00070030 user32!InternalCallWinProc+0x20
41 01bbf7b4 77b690dc 0035eb2f 00000000 00000202 user32!UserCallWinProcCheckWow+0x1be
42 01bbf820 77b5b2ee 21141d48 21141d48 041076c8 user32!DispatchMessageWorker+0x4ac
43 01bbf854 0035d997 000c0ce0 041076c8 041076c8 user32!IsDialogMessageW+0x17e
44 01bbf868 00361a90 041076c8 01bbf888 00369bc4 HRDLogbook!CWnd::IsDialogMessageW+0x2e [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 193]
45 01bbf874 00369bc4 041076c8 21141d48 041076c8 HRDLogbook!CWnd::PreTranslateInput+0x2b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 4589]
46 01bbf888 0032d83c 041076c8 21141d48 000c0ce0 HRDLogbook!CDialog::PreTranslateMessage+0xa0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgcore.cpp @ 79]
47 01bbf89c 0090ab6f 041076c8 041076c8 000c0c34 HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::PreTranslateMessage+0x7c [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 183]
48 01bbf9a4 003628b0 041076c8 041076c8 0beb5020 HRDLogbook!CLogbookFull::PreTranslateMessage+0x3cf [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 6041]
49 01bbf9b8 003679e8 000c0c34 041076c8 041076c8 HRDLogbook!CWnd::WalkPreTranslateTree+0x21 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3363]
4a 01bbf9d4 00367f22 041076c8 01bbf9f0 008a7c16 HRDLogbook!AfxInternalPreTranslateMessage+0x3f [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 233]
4b 01bbf9e0 008a7c16 041076c8 04107698 01bbf9fc HRDLogbook!CWinThread::PreTranslateMessage+0xb [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 777]
4c 01bbf9f0 00367abc 041076c8 01bbfa28 00367a6d HRDLogbook!CHRDLogbookApp::PreTranslateMessage+0x26 [c:\ham radio\logbook\hrdlogbook\hrdlogbook.cpp @ 1487]
4d 01bbf9fc 00367a6d 041076c8 00000000 00cbf380 HRDLogbook!AfxPreTranslateMessage+0x17 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 255]
4e 01bbfa0c 003680b7 ffffffff 00cbf380 00cbf380 HRDLogbook!AfxInternalPumpMessage+0x2b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 178]
4f 01bbfa28 007a5704 0049c565 00000001 00000000 HRDLogbook!CWinThread::Run+0x57 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 629]
50 01bbfa3c 0049c4eb 00320000 00000000 040f2038 HRDLogbook!AfxWinMain+0x66 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 47]
51 01bbfa88 75918654 01c7a000 75918630 16ef8252 HRDLogbook!__tmainCRTStartup+0xfd [f:\dd\vctools\crt\crtw32\startup\crt0.c @ 251]
52 01bbfa9c 77da4a77 01c7a000 76890fe1 00000000 kernel32!BaseThreadInitThunk+0x24
53 01bbfae4 77da4a47 ffffffff 77dc9ebb 00000000 ntdll!__RtlUserThreadStart+0x2f
54 01bbfaf4 00000000 0049c565 01c7a000 00000000 ntdll!_RtlUserThreadStart+0x1b


2018-04-10 11:46

viewer   ~0004798

OK Mike. Large dumps it is.


2018-04-11 08:52

manager   ~0004799

G3UCQ, can you characteraize your completion of the QSO entry when the crash happens?

After entering a QSO, maybe you press the "Add" button by clicking it. Or, maybe you press F7. I think you could press the [Enter] key; but maybe I'm wrong. Do you use the [X] close button on the title bar, or maybe press ALT+F4 to close the window?


2018-04-11 09:14

viewer   ~0004800

If the data is not populated I may press Lookup. I always press the ADD button, never F7 as I am using the mouse.
Then the CANCEL button. HTH


2018-04-11 09:42

manager   ~0004801

Last edited: 2018-04-11 09:42

View 2 revisions

I spent a little bit more time with this newest minidump and found something interesting.

The code that's crashing is looping over an array with this structure:

struct {
    CDialogWndBase* pDialog;
    int nIDD;
    LPCTSTR lpszTitle;
    BOOL bAdjustTab;
} aTabs[];

where each entry in the array ias some information about one of the tabs in the ALE. The first member in the structure is a pointer to a member of the CLogbookFull class, which represents the whole ALE. The list is initialized like this:

aTabs[] = {
    &m_wndLogbook, CLogbookWndLogbook::IDD, _T("Logbook"), TRUE, // 0
    &m_wndWorked, CLogbookWndWorked::IDD, _T("Worked"), TRUE,
    &m_wndCountry, CLogbookWndCountry::IDD, _T("Country"), TRUE,
    &m_wndContact, CLogbookWndContact::IDD, _T("Contact"), TRUE,
    &m_wndLocation, CLogbookWndLocation::IDD, _T("Location"), TRUE,
    &m_wndIOTA, CLogbookWndIOTA::IDD, _T("IOTA"), TRUE,
    &m_wndAntSat, CLogbookWndAntSat::IDD, _T("Ant/Sat"), TRUE,
    &m_wndAward, CLogbookWndAward::IDD, _T("Award"), TRUE,
    &m_wndContest, CLogbookWndContest::IDD, _T("Contest"), TRUE,
    &m_wndCustom, CLogbookWndCustom::IDD, _T("Custom"), TRUE,
    &m_wndMyStation, CLogbookWndMyStation::IDD, _T("My Station"), FALSE,
    &m_wndPropagation, CLogbookWndPropagation::IDD, _T("Propagation"), TRUE,
    &m_wndQSL, CLogbookWndQSL::IDD, _T("QSL"), TRUE, // 12
    &m_wndeQSL, CLogbookWndeQSL::IDD, _T(""), TRUE,
    &m_wndLOTW, CLogbookWndLOTW::IDD, _T("LOTW"), TRUE, // 14

The loop is simple enough; it calls the Reset() member of each of the tabs:

    for (int nTab = 0; nTab < ARRAYSIZE(aTabs); nTab++)

Any of the mindumps provided so far always show that the crash happens when the code is trying to call Reset() on the m_wndQSL entry in the array. That fact is known because we can study the optimized assmebly code and discover that the loop starts with EBX = 15 (decimal), which is the number of entries in the aTabs array; and counts downward as the loop moves forward in the array. The loop processes an entry, decrements EBX, and continues looping if EBX is not equal to zero. EBX ranges from 15 to 1 while calling Reset().

Here is as much of the loop as we can see without tripping over optimized (scheduled) code:

0090a09d 8d4900 lea ecx,[ecx]
0090a0a0 8b0e mov ecx,dword ptr [esi]
0090a0a2 8b01 mov eax,dword ptr [ecx]
0090a0a4 ff9088010000 call dword ptr [eax+188h]
0090a0aa 8d7610 lea esi,[esi+10h]
0090a0ad 4b dec ebx
0090a0ae 75f0 jne HRDLogbook!CLogbookFull::OnReset+0x730 (0090a0a0)

From this much code, we can see that we're carrying a pointer to the entries in the aTabs array in ESI, and that loop counter in EBX.

0:000> r
Last set context:
eax=00a81690 ebx=00000003 ecx=21156eb8 edx=00000000 esi=01bbe354 edi=21141d48
eip=00000004 esp=01bbe258 ebp=01bbe594 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206
00000004 ?? ???

When the crash happens, EBX is 3, which means we're at at the 15-3 == 12th index in the array, marked by the "12" comment above.

That we crash in the middle of the loop means we've processed other entries without trouble. We've most recently processed the m_wndPropagation array entry.

Reset() is a virtual function, so the call to Reset() goes through the vtable of the object being called. At 90A0A4 above, the CALL statement to call the Reset() method exists. We expect the vtable address for the class in the EAX; it came from dereferencing ESI (the variable used to walk the array entries), then deferencing the pDialog pointer to find the vtable of the function.

If EAX is the vtable for CLogbookWndQSL, we should be able ot demonstrate that by finding the symbol. But the nearest symbol is a plain CWnd vftable:

0:000> ln a81690
Browse module
Set bu breakpoint

(00a81690) HRDLogbook!CWnd::`vftable' | (00a817f4) HRDLogbook!CCriticalSection::`vftable'
Exact matches:

Dumping the vtable at the address A81690 doesn't work quite right, either:

0:000> dps a81690
00a81690 0035fe61 HRDLogbook!CWnd::GetRuntimeClass [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 5156]
00a81694 0035e1da HRDLogbook!CWnd::`scalar deleting destructor'
00a81698 0032a300 HRDLogbook!CObject::Serialize [c:\program files (x86)\microsoft visual studio 12.0\vc\atlmfc\include\afxwin2.inl @ 561]
00a8169c 00364b17 HRDLogbook!CCmdTarget::OnCmdMsg [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 295]
00a816a0 003607ed HRDLogbook!CWnd::OnFinalRelease [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 944]
00a816a4 0049643c HRDLogbook!CMFCHeaderCtrl::OnEraseBkgnd [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\afxheaderctrl.cpp @ 214]
00a816a8 00336280 HRDLogbook!CXTPControl::OnSetPopup [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpcontrol.h @ 2337]
00a816ac 0032f560 HRDLogbook!CMDIChildWnd::IsTabbedMDIChild [c:\program files (x86)\microsoft visual studio 12.0\vc\atlmfc\include\afxwin.h @ 4432]
00a816b0 0032f560 HRDLogbook!CMDIChildWnd::IsTabbedMDIChild [c:\program files (x86)\microsoft visual studio 12.0\vc\atlmfc\include\afxwin.h @ 4432]
00a816b4 00364b0f HRDLogbook!CCmdTarget::GetTypeLib [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 409]
00a816b8 0035ff80 HRDLogbook!CWnd::GetThisMessageMap [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 1967]

I've built a release build on my desktop and can confirm that the expected types and addresses appear in the EAX register when looping here. This is new information, since I had previously believed the vtable pointer in EAX to be correct, but the memory had been corrupted.

Now, I'm considering two other possibilities:

First, maybe my interpretation of the symbols and their meanings isn't spot-on. That would be pretty shocking, though, since windbg is so aggressive about assuring that the right symbols are in the right place. Sitll, I guess my assumptions/knowledge of the structure of the vtable setup might be flawed.

Second, perhaps something is altering the vtable pointer in the m_wndQSL object which we've got here. That would mean another message or thread has come along and done some work while we were looping in this thread.

What could cause such behaviour?

Let's look at the Reset() implementations of the functions called so far:

    m_pwndLogbook: deletes all entries in its list control, posts a message to itself to resize
    m_pwndWorked: marks a member variable, posts a message to itself to reset its content
    m_pwndCountry: Resets the callsign to empty strings
    m_pwndContact: visits each child window finding "edit" and "mfceditbrowse" windows; for those, resets content.
    m_pwndLocation: visits each child window finding "edit", "mfceditbrowse", and "combobox" windows; for those, resets their content.
    m_pwndIOTA: Directly resets the name, island, comment controls.
    m_pwndAntSat: visits each child window finding "edit" and "mfceditbrowse" windows; for those, resets content.
    m_pwndAward: no implementation (empty function)
    m_pwndContest: visits each child window finding "edit" and "mfceditbrowse" windows; for those, resets content.
    m_pwndCustom: visits each child window finding "edit" and "mfceditbrowse" windows; for those, resets content.
    m_pwndMyStation: no implementation (empty function)
    m_pwndPropagation: visits each child window finding "edit" and "mfceditbrowse" windows; for those, resets content. Then calls Track(), which has a message pump.
//---- not called yet:
    m_pwndQSL: directly reset the QSL sent/received, sent/received via boxes
    m_pwndeQSL: directly reset the sent/received boxes
    m_pwndLOTW: directly reset the sent/received boxes

So, something sticks out immediately: the Reset() implementation of CLogbookWndPropagation will take it upon itself to pump its own messages. Private message pumps permiate this cdoe base; they're almost never necessary, and always dangerous. In this case, I figure the message pump is letting pass a close message that isn't expected, or isn't handled as expected. Shutdown of the dialogs ensues, and the vtable ends up referencing the wrong spot.

I'll make a speculative fix that removes the message pump. As in most cases, it's pointless. Here, it appears to be implemented in the belief that the tracking messages won't flow (quickly enough?) when tracking of the propogation setting is toggled.


2018-04-12 05:31

viewer   ~0004805

Excellent on all that but wish I could understand it.
Just had another crash but this time I was not using the Logbook.
It was open along with Rig Control and DM780.
I was trying to work 3B7A on 15m FSK RTTY when the Logbook stopped working.
No dump file was created but there was a message asking to Debug. I cancelled that and the Logbook closed.
I have not seen this happen before. I do not think it is RFI as RF has never caused any HRD modules to close before.


2018-04-12 12:43

manager   ~0004806

I need to use Mantis to track my work. My work is very technical in nature, particularly when using information in a minidump to investigate a bug. Customers aren't the intended audience for this contact. However, if I mark the notes as "Private", it would leave the impression that I'm not doing any work on the issue at all.

If you have a crash thatn's not related to this issue, please open another issue and add the minidump and the repro steps to that new issue.

If, by "RFI" you mean "radio frequency interference", I agree. RFI would be among the least likely causes I would consider for the diagnosis of a software problem.


2018-04-12 13:20

manager   ~0004807

I've checked in a fix that removes the message pump from the Track() method described above. Please let me know if the situation improves in the upcoming builds -- if you're still crashing with this path, a larger, "full" minidump would be useful.

Thanks for your patience and feedback while I'm trying to diagnose this issue!


2018-04-12 14:13

viewer   ~0004808

Is there anyway to create a full minidump if one is not automatically created? Failing that would any information from the Debug help?
Tell me what to do please? I am grateful for your continued work on this.


2018-04-12 18:51

manager   ~0004813

I'm not sure what you mean by "information from the Debug help". Can you please provide some clarification?

I guess it 's possible something is wrong with the code we've got to create minidumps, but I think it's safe to say that if a minidump file isn't created, you're not actually crashing. You've always provided a minidump, so you're always crashing.

What I mean by a "full" dump is to make sure you've got the Minidump size setting in the global options window set to "large". That way, the dump file contains all the memory in the process. You can find instructions for setting the minidump size in this forum post:


2018-04-13 03:20

viewer   ~0004814

Re. the Logbook closing without a minidump. There was a message saying Logbook has to close and an option to Debug or Cancel.
I chose Cancel. I have now read your info on all this so can use Task Manager to create a dump file if one is not created automatically. I do have 'large' set in global options.


2018-04-16 03:40

viewer   ~0004837

Another "Logbook stopped responding" issue.
Open were Rig Control, Logbook and DM780.
Trying to work 3B7A on 20m FSK.
My only interaction was to be clicking the DM780 macro to send my call sign to 3B7A.
Calling for about 20 minutes (without success!)
It was then when the Logbook stopped responding and had to close.
I started the Steps Recorder and the result is attached. (834,746 bytes)


2018-04-16 09:58

manager   ~0004842

The attached ZIP file contains an MHT file; I don't know what that is -- what am I meant to use to view it?

Do you have a minidump available from this crash?


2018-04-16 10:37

viewer   ~0004843

The .mht file was created by Task Manager. It can be viewed in a browser.
Sorry, no mini dump file was created.
The Logbook just suddenly stopped working, closed, and I got the messages you will see when you open the .mht file.


2018-04-19 11:07

manager   ~0004858

The MHT file doesn't tell me anything useful; it just says you saw a window announcing a crash.

I can't figure out how this report relates to the issue you were having here (0002199) with the ALE window. Can you explain why you've attached this report to this issue, and not created a new Mantis issue for it?


2018-04-19 12:45

viewer   ~0004859

The Logbook stopped responding out of the blue. I assumed it was the same problem. Sorry.


2018-04-20 08:19

viewer (25,600,790 bytes)


2018-04-20 08:19

viewer   ~0004862

Logbook stopped responding again.
Running were Rig Control and Logbook with the Cluster. Nothing else.
I worked 9X5PJ and right clicked the call on the cluster to open the ALE.
Info was populated correctly and I clicked on the ALE button 'Update'.
The ALE closed and immediately got a message saying that Logbook had to close.
The large dump file is attached. HTH.


2018-04-22 19:00

manager   ~0004880

G3UCQ_HRDLogbook_20180420_130516 is the same stack as presented previously in this issue, where a call is made to Reset() on the objects, but the vtable pointer dereferenced on one of the 15 in the list (uh, right? 12?) is bogus. I think the fix I've made will take care of it, so we can see with the next build ...


2018-05-01 08:11

viewer (26,392,508 bytes)


2018-05-01 08:11

viewer   ~0004915

In case yet another dump file is useful one is attached.
Open were Rig Control, Logbook with cluster and the Rotator (to see if that would stop responding!)
After logging about 6 QSOs the Logbook stopped responding after the final QSO.
Add button was clicked and that prompted the Logbook to stop responding.


2018-05-01 09:07

manager   ~0004918

The "g3ucq_HRDLogbook_20180501_130149" dump file demonstrates the same bad vtable pointer we've been working. I think this issue is fixed; we've just got to ship it ...


2018-05-01 10:14

viewer   ~0004919

Another crash. Cannot wait for the next build!


2018-05-04 14:10

viewer (26,459,490 bytes)


2018-05-04 14:10

viewer   ~0004950

Yet another problem with the same sequences as above having entered about 10 QSOs with no problems.
Build .837


2018-05-04 19:12

manager   ~0004955

OK, so there's good news and bad news.

The bad news is: as far as I know, this is only happening to you. There's certainly bad code here, but you're the only reporter of this issue that I'm aware of. That menas there's something unique to your machine (as far as our customer base goes) which is causing this problem. It's also possible that you're doing something unique that [most] other users don't do that exacerbates the issue. That's why I've asked about all the details, or hoped that you would provide a recording showing what you're doing.

The good news is: while the fix I made didn't resolve this issue, it made it better. The new Minidump you've provided crashes further along than the we were getting before. That measn I've correctly diagnose the problem; I just need to make a fix that's good enough to solve the whole issue.

These notes are mostly for me, so I won't apologize for them being too technical, but here's what's going on:

Pressing ADD to accept the ALE window's content does two things: it does the work to add the record, and it also clears the data in the window so that the next record can be created. The window is huge; there are the controls that don't move around at the top half of the window; and there are 12 tabbed dialog boxes, each with their own set of controls, at the bottom of the window. In the code, the process of clearing the main window and all the tabbed windows is called "resetting".

The stack shows that OnReset() is where the crash occurrs; here's the newest call stack, omiiting a couple dozen of the lower frames:

 # ChildEBP RetAddr  Args to Child              
00 01d5e2f4 008ba222 b84d8f6f 00000111 00000000 0x4
01 01d5e634 00315190 00000000 0ad6bdc0 01d5e674 HRDLogbook!CLogbookFull::OnReset+0x862 [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 6315] 
02 01d5e644 00314fc9 0ad6bdc0 00004f95 00000000 HRDLogbook!_AfxDispatchCmdMsg+0x42 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 78] 
03 01d5e674 0032567b 00004f95 00b4146c 00000000 HRDLogbook!CCmdTarget::OnCmdMsg+0x120 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\cmdtarg.cpp @ 373] 
04 01d5e698 003109aa 00004f95 00000000 00000000 HRDLogbook!CPropertySheet::OnCmdMsg+0x1b [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dlgprop.cpp @ 816] 
05 01d5e6e8 00311597 00004f95 00000000 b84d8efb HRDLogbook!CWnd::OnCommand+0x89 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2784] 
06 01d5e7a0 002dd896 00000111 00004f95 00000000 HRDLogbook!CWnd::OnWndMsg+0x3c [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2108] 
07 01d5e7bc 00312d4f 00000111 00004f95 00000000 HRDLogbook!CXTPDialogBase<CXTPResizeDialog>::OnWndMsg+0x46 [c:\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\commandbars\xtpdialogbase.h @ 194] 
08 01d5e7dc 0030e817 00000111 00004f95 00000000 HRDLogbook!CWnd::WindowProc+0x22 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 2094] 
09 01d5e84c 0030efcc 0ad6bdc0 000209f4 00000111 HRDLogbook!AfxCallWndProc+0xb0 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 285] 
0a 01d5e86c 7534e0bb 000209f4 00000111 00004f95 HRDLogbook!AfxWndProc+0x34 [f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 434] 
0b 01d5e898 75358849 0030ef98 000209f4 00000111 user32!_InternalCallWinProc+0x2b
0c 01d5e8bc 7535b145 00000111 00004f95 00000000 user32!InternalCallWinProc+0x20
0d 01d5e98c 7535833a 0030ef98 00000000 00000111 user32!UserCallWinProcCheckWow+0x1be
0e 01d5e9d0 7533fbab 00000111 00004f95 00000000 user32!CallWindowProcAorW+0xd4
0f 01d5e9e8 00596d9c 0030ef98 000209f4 00000111 user32!CallWindowProcW+0x1b
10 01d5ea30 7534e0bb 0030ef98 00000111 00004f95 HRDLogbook!CXTPHookManager::HookWndProc+0xac [c:\hrdbranch\ham radio\codejock software\mfc\xtreme toolkitpro v15.0.2\source\common\xtphookmanager.cpp @ 267] 
11 01d5ea5c 75358849 00596cf0 000209f4 00000111 user32!_InternalCallWinProc+0x2b
12 01d5ea80 7535b145 00000111 00004f95 00000000 user32!InternalCallWinProc+0x20
13 01d5eb50 75348503 00596cf0 00000000 00000111 user32!UserCallWinProcCheckWow+0x1be
14 01d5ebb8 75348aa0 04be9140 00000000 00000111 user32!DispatchClientMessage+0x1b3
15 01d5ec00 77d40c6d 01d5ec1c 00000020 01d5ed74 user32!__fnDWORD+0x50
16 01d5ec38 77cb2a4c 7535a9fd 000209f4 00000111 ntdll!KiUserCallbackDispatcher+0x4d
17 01d5ec3c 7535a9fd 000209f4 00000111 00004f95 win32u!NtUserMessageCall+0xc
18 01d5eca8 7533b95b 04be9140 00000000 00000000 user32!SendMessageWorker+0x860
19 01d5ecd4 008c0997 000209f4 00000111 00004f95 user32!SendMessageW+0x5b
1a 01d5ed8c 00315190 00000000 0ad6bdc0 01d5edcc HRDLogbook!CLogbookFull::OnOK+0x6e7 [c:\ham radio\logbook\hrdlogbook\logbookfull.cpp @ 4267] 

OnOK() executes when the user presses "Add". The code sends WM_COMMAND message with IDC_RESET to itself, which is silly; why not just call the OnReset() method directly? It then loops around to call all the OnReset() method on each of the tabs.

The previous fix removed a message pump (!!) from the tabs, which let other messages be processed during IDC_RESET, which changed the states of the dialog and screwed-up the works. Specifically, it looks like a WM_CLOSE message is being processed by the message loop and windows end up disappearing.

The newest callstack is still in OnReset(), but much further along. It's past the loop which calls Reset() for each tab.

Amazingly, the OnReset() functions somehow aren't adequate. After the OnReset() loop, some more Reset() is called on the ITOA window again. A couple of fields are set, and member variables changed. The code, at the point of this crash, is about to call into the IOTA tab to have it reset itself again, then touch some more member fields.

Just before this code is a message pump; there can be little doubt that this pump is processing a WM_CLOSE message that deletes window objects; when they're again referenced, they're invalid and the crash occurrs.


2018-05-04 19:13

manager   ~0004956

Added with this checkin


2018-05-05 03:00

viewer   ~0004957

I do not see how I can do anything different to what I am doing already.
Open the ALE either from the ADD button or a right click on a cluster spot.
Check the data is OK, press Lookup for info and then press the F7 button.
I am not the only one with this problem as these threads show.


2018-05-05 09:55

manager   ~0004959

The problem you're reporting is a crash, which stops execution and creates a minidump.

The problem the threads report is a hang, which doesn't stop execution and doesn't create a minidump.

The symptoms are very much different.


2018-05-05 15:40

viewer   ~0004960

I give up.


2018-05-05 17:10

manager   ~0004961

Give up?! Holy smokes, why?

The build you're testing shows that I've got the right diagnosis. The new crash you've found is different; and it shows we're making progress. (Sometimes, one bug masks another.)

We wouldn't have made it that far without your consistent reporting, and uploading dumps. Of the beta testers that I've worked with, you're the most patient and clear in reporting issues, and we couldn't have made it this far without you.

Why would you give up? We need your help.


2018-05-05 17:43

viewer   ~0004962

Mike, I just received an email (see the thread in the Beta Forum) which really wound me up so your comment that the crash and hanging were different did not make sense and frustration got the better of me. I really appreciate your comments on my reporting. Thank you for that.


2018-05-06 11:46

manager   ~0004965

There are lots of bugs in the product; any product has at least a few bugs. The bug we're working on here is one of them.

Other bugs might produce a crash, too, but have different causes. Other bugs might produce a hang (which is different behaviour than a crash) . Since the symptoms are different, we can be pretty sure that the actual cause of the bug in this issue is different than the issues reported in the threads you've linked.

Maybe it turns out that they're related, or even the same -- but that's pretty unlikely, since the symptoms are different.

I'm working on this issue with you because you've been responsive in explaining what you're doing to cause the crash. I can't reproduce the problem myself, and I haven't heard from other users who have this same issue. For sure, there are other ways to make the logbook crash. I have to find them, categorize them, and try to find the cause of each. Sometimes, that process is easy. Sometimes, it's difficult to discover the cause of a crash and it reuqires lots of investigation. In any case, every detail helps; we never know which detial might crack the case.

I hope that makes my comment (and the process) clearer.


2018-05-06 13:45

viewer   ~0004966

Thank you Mike. I really appreciate the time you are spending on this.
Do you not think it is something in my system that is causing the problem or is it definitely a bug in the software?
If it is something in my system I would prefer you did not continue pursuing it as there are other problems to solve.


2018-05-06 17:06

manager   ~0004968

I think there are three possibilities:

1) There's a bug in the code.

2) There's something wrong with your computer.

3) There's a bug in the code that only reveals itself (or is more likely to reveal itself) on your computer; due to your usage pattern of the program or due to some configuration setting you've got in the application or your operating system.

I think #3 is the most likely explanation of what we're seeing.

A few posts ago, you said that you killed a system service and that caused the Logbook to crash. I would put that down as #2; we can't expect any application to be stable when critical system services are arbitrarily terminated.

I've asked about your usage pattern, and it doesn't seem like anything too out of the ordinary. Maybe there's some application you've got that makes your computer look a little different to the HRD software. That's a problem with the HRD software, though. It should be resilient to reasonable configurations of systems.

I've identified and fixed code in the Logbook application that affects the problem you're seeing, and those changes have made progress. In the next beta build, you'll see the effects of another such change. Either we'll discover the next snag, or we'll realize that your issue is acutally cured.

I'm able to prioritize my own time. I don't think having users make prioritization decisions for me (or for the product as a whole) is healthy. I think you should keep reporting and updating issues as you have been.

I know this process can be frustrating for users. I'm outnumbered in every dimension; there's only one of me, but there are a couple dozen beta users, a dozen applications in the suite ,hundreds of bugs, tens of thousands of customers, and more than a million lines of code. Some issues are more inovlved than others. I make progress with them as rapidly as I can, and I appreciate your patience.


2018-05-08 09:11

viewer (25,568,420 bytes)


2018-05-08 09:11

viewer   ~0004972

Yet another 'crash'. Running in the background was a disk partitioning software moving partitions but not on my C: drive.
Added one QSO using the ALE and Add button, then another and had the problem.
I have tried to setup a VM using Virtualbox but am unable to install the Icom drivers to give the COM ports. That would be a totally clean Windows 10 install if I can get it working.


2018-05-13 15:38

manager   ~0005035

It looks like your minidump came from build 837. Did you notice any improvement when running build 839? That's the first build that contains my change number 4107.


2018-05-14 02:45

viewer   ~0005039

It is early days but I have not had a problem lately. What few QSOs I have made have entered OK. Fingers crossed :-)


2018-05-14 09:06

manager   ~0005042

OK. Please keep us posted. With 840, things should either be fixed or move on to the next snag ... so crash reports with 840 and newer are meaningful.


2018-05-14 10:28

viewer   ~0005043

Thank you. I have given up on the VM project due to problems with the Icom drivers so am working on a dual boot system with a clean installation of Windows 10, 64 bit Home.


2018-05-16 04:24

viewer   ~0005061

I now have a dual boot system with a clean installation of Windows 10 64 bit Home along with my original Windows 10.
On the new install, I used the Cluster to load 20 QSOs through the ALE without a problem.
Loaded the original OS and repeated the process. Again no problems.
So fingers crossed it is looking good.


2018-05-16 09:42

manager   ~0005064

Glad to hear it. Please let me know if you'd be comfortable resolving this bug.


2018-05-23 08:56

viewer   ~0005092

I think we can safely say you have cracked this one. Since installing build .840 I have logged 50 QSOs without a problem.
Well done.


2018-05-23 09:48

manager   ~0005093

Awesome! Thank you for your patience and diligence. Sorry it took so long, but it was a very involved issue.

I'll mark it resolved now, and we can sweep it up in the next release cycle.


2018-05-23 09:48

manager   ~0005094

finally fixed! \o/


2018-05-29 15:11

administrator   ~0005140

I've never had this problem. (Appreciate that John did... but if everyone had this problem, we'd be in DEEP trouble). So I can't test it. I'll take John's word for it. Is the "Fixed in Version" number supposed to be 840 then?


2018-05-29 15:28

viewer   ~0005144

Yes, fixed in 840.

Issue History

Date Modified Username Field Change
2017-08-13 03:01 g3ucq New Issue
2017-08-13 03:01 g3ucq File Added: HRDLogbook.dmp
2017-08-17 22:53 K7ZCZ Note Added: 0004015
2017-08-17 22:53 K7ZCZ Note Added: 0004016
2017-08-17 23:20 K7ZCZ Note Added: 0004019
2017-08-21 08:45 g3ucq File Added: HRDLogbook-2.dmp
2017-08-21 08:45 g3ucq Note Added: 0004066
2017-09-05 10:54 K7ZCZ Assigned To => K7ZCZ
2017-09-05 10:54 K7ZCZ Status new => assigned
2017-09-12 22:15 K7ZCZ Note Added: 0004180
2017-09-22 14:19 K7ZCZ Relationship added has duplicate 0002253
2018-03-11 08:19 K7ZCZ Relationship added related to 0002596
2018-03-16 06:08 g3ucq Note Added: 0004493
2018-04-05 10:56 g3ucq File Added:
2018-04-05 10:56 g3ucq Note Added: 0004701
2018-04-05 17:56 K7ZCZ Note Added: 0004708
2018-04-07 02:59 g3ucq Note Added: 0004737
2018-04-07 05:30 g3ucq File Added:
2018-04-07 05:30 g3ucq Note Added: 0004742
2018-04-07 08:52 K7ZCZ Note Added: 0004744
2018-04-07 10:31 g3ucq Note Added: 0004746
2018-04-07 10:36 g3ucq Note Added: 0004747
2018-04-09 14:58 g3ucq File Added:
2018-04-09 14:58 g3ucq Note Added: 0004783
2018-04-10 03:02 g3ucq File Added: G3UCQ_2018-04-10
2018-04-10 03:02 g3ucq Note Added: 0004791
2018-04-10 08:48 K7ZCZ Note Added: 0004792
2018-04-10 09:14 g3ucq Note Added: 0004793
2018-04-10 09:52 K7ZCZ Note Added: 0004794
2018-04-10 10:35 g3ucq Note Added: 0004795
2018-04-10 11:13 K7ZCZ Note Added: 0004796
2018-04-10 11:46 g3ucq Note Added: 0004798
2018-04-11 08:52 K7ZCZ Note Added: 0004799
2018-04-11 09:14 g3ucq Note Added: 0004800
2018-04-11 09:42 K7ZCZ Note Added: 0004801
2018-04-11 09:42 K7ZCZ Note Edited: 0004801 View Revisions
2018-04-12 05:31 g3ucq Note Added: 0004805
2018-04-12 12:43 K7ZCZ Note Added: 0004806
2018-04-12 13:20 K7ZCZ Note Added: 0004807
2018-04-12 14:13 g3ucq Note Added: 0004808
2018-04-12 18:51 K7ZCZ Note Added: 0004813
2018-04-13 03:20 g3ucq Note Added: 0004814
2018-04-13 10:22 WA9PIE Severity major => crash
2018-04-13 10:23 WA9PIE Project 1 - Backlog => 3 - Current Dev List
2018-04-16 03:40 g3ucq File Added:
2018-04-16 03:40 g3ucq Note Added: 0004837
2018-04-16 09:58 K7ZCZ Note Added: 0004842
2018-04-16 10:37 g3ucq Note Added: 0004843
2018-04-19 11:07 K7ZCZ Note Added: 0004858
2018-04-19 12:45 g3ucq Note Added: 0004859
2018-04-20 08:19 g3ucq File Added:
2018-04-20 08:19 g3ucq Note Added: 0004862
2018-04-22 19:00 K7ZCZ Note Added: 0004880
2018-05-01 08:11 g3ucq File Added:
2018-05-01 08:11 g3ucq Note Added: 0004915
2018-05-01 09:07 K7ZCZ Note Added: 0004918
2018-05-01 10:14 g3ucq Note Added: 0004919
2018-05-04 14:10 g3ucq File Added:
2018-05-04 14:10 g3ucq Note Added: 0004950
2018-05-04 19:12 K7ZCZ Note Added: 0004955
2018-05-04 19:13 K7ZCZ Note Added: 0004956
2018-05-05 03:00 g3ucq Note Added: 0004957
2018-05-05 09:55 K7ZCZ Note Added: 0004959
2018-05-05 15:40 g3ucq Note Added: 0004960
2018-05-05 17:10 K7ZCZ Note Added: 0004961
2018-05-05 17:43 g3ucq Note Added: 0004962
2018-05-06 11:46 K7ZCZ Note Added: 0004965
2018-05-06 13:45 g3ucq Note Added: 0004966
2018-05-06 17:06 K7ZCZ Note Added: 0004968
2018-05-08 09:11 g3ucq File Added:
2018-05-08 09:11 g3ucq Note Added: 0004972
2018-05-13 15:38 K7ZCZ Note Added: 0005035
2018-05-14 02:45 g3ucq Note Added: 0005039
2018-05-14 09:06 K7ZCZ Note Added: 0005042
2018-05-14 10:28 g3ucq Note Added: 0005043
2018-05-16 04:24 g3ucq Note Added: 0005061
2018-05-16 09:42 K7ZCZ Note Added: 0005064
2018-05-23 08:56 g3ucq Note Added: 0005092
2018-05-23 09:48 K7ZCZ Note Added: 0005093
2018-05-23 09:48 K7ZCZ Status assigned => resolved
2018-05-23 09:48 K7ZCZ Resolution open => fixed
2018-05-23 09:48 K7ZCZ Testing => Not Started
2018-05-23 09:48 K7ZCZ Note Added: 0005094
2018-05-26 23:31 K7ZCZ Fixed in Version =>
2018-05-29 15:11 WA9PIE Note Added: 0005140
2018-05-29 15:11 WA9PIE Testing Not Started => Beta Successful
2018-05-29 15:28 g3ucq Note Added: 0005144
2018-06-01 23:20 WA9PIE Status resolved => closed
2018-06-01 23:20 WA9PIE Fixed in Version =>
2018-06-01 23:21 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe