View Issue Details

IDProjectCategoryView StatusLast Update
00021993 - Current Dev ListBugpublic2018-04-20 08:19
Assigned ToK7ZCZ 
Status assignedResolutionopen 
Product Version 
Target VersionFixed in Version 
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


has duplicate 0002253 closedK7ZCZ Ham Radio Deluxe HRD Logbook stops responding 
related to 0002596 resolvedK7ZCZ 3 - Current Dev List 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

updater   ~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

updater   ~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

updater   ~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

updater   ~0004737

Entered 10 QSOs without a problem so fingers crossed.


2018-04-07 05:30

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~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

updater   ~0004859

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


2018-04-20 08:19

updater (25,600,790 bytes)


2018-04-20 08:19

updater   ~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.

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