View Issue Details

IDProjectCategoryView StatusLast Update
00033101 - BacklogBugpublic2019-05-06 23:22
ReporterKB3NPHAssigned ToKB3NPH 
PriorityhighSeveritycrashReproducibilityalways
Status resolvedResolutionunable to reproduce 
Summary0003310: V6.5.0.207 crashing when Logbook closes
DescriptionThis could be related to another issue but I was not able to locate one. While in a remote with a customer about an unrelated issue, discovered that when the Logbook is shut down normally, terminating by using the red [X] in the upper right corner, as long as the customer is NOT connected to a DX Cluster node, the logbook closes normally. Meaning that it does the backup if any changes were made in the Logbook during the session, then the logbook closes as expected.

If the customer has the DX Cluster connected to any node and closes the Logbook using the red [X], the logbook will do the normal closing backup, if there have been changes to the log, then it will close generating a mini-dump file.

As long as the DX cluster is not connected to a node the logbook will shut down normally. As soon as the customer attempts to close down the logbook WITH the DX Cluster connected, the logbook will close and generate a mini-dump file.

During the day there were 4 crashes where mini-dumps were generated. Two dumps were zero byte files created prior to our remote. 2 were generated during the remote, one is a zero bypt file. All have been added to the "Mantis 3310" folder in the DUMP folder on G-Drive. The zero byte files were included just to indicate that a dump file is being created but doesn't always contain any data.

  Ticket# 250510 - The customer is running Windows 7 64-bit with more than 6GB of Ram installed. The logbook database contains 180+ contacts. While in the remote I checked and there are about 6 databases configured in the system. His original problem was resolved by un-checking the WSI check for all but his MAIN database, where he stores ALL of his contacts.


TagsNo tags attached.
ModuleLogbook
Sub-Module(select)
TestingNot Started

Relationships

related to 0002732 closedPD9FER 4 - Closed w/o Action Logbook crashing when idle 
related to 0002808 closedPD9FER 4 - Closed w/o Action Logbook: Crash in MySQL driver on Windows 7 machines 

Activities

PD9FER

2019-05-06 14:05

updater   ~0007913

Did a Remote with Customer.
He had ODBC connector V5.x installed.
I uninstalled it and installed the 32 Bit V8.x version.
Problem went away.

Can we put a check into our installer to see if they using a V5 ODBC?
And inform they should replace it with V8.x?

K7ZCZ

2019-05-06 23:21

manager   ~0007916

There are four dump files on Google drive. These three:

HRDLogbook_20190403_102828.mdmp
HRDLogbook_20190403_102947.mdmp
HRDLogbook_20190403_190714.mdmp


are zero bytes in length and not viable.

The file HRDLogbook_20190403_190004.mdmp contains a readable dump, but it is from version .202 of the product, and that doesn't match the version .207 that's mentioned in the bug summary.

0:005> lmDvmHRDLogbook
Browse full module list
start    end        module name
010f0000 02a6f000   HRDLogbook   (deferred)             
    Image path: C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe\HRDLogbook.exe
    Image name: HRDLogbook.exe
    Browse all global symbols  functions  data
    Timestamp:        Thu Mar  7 10:04:28 2019 (5C815D2C)
    CheckSum:         0175BE6E
    ImageSize:        0197F000
    File version:     6.5.0.202
    Product version:  6.5.0.202
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        1.0 App
    File date:        00000000.00000000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4


I don't think we ever released 6.5.0.202, so it seems like I'm bein asked to support an unreleased version. (It doesn't appear the Change Log.)

The call stack in the viable dump is here:

0:005> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 0833f00c 77c7e0c3 3b010d70 00000004 ffffffff ntdll!RtlpLowFragHeapFree+0xc5
01 0833f024 762914bd 00630000 00000000 3b010d70 ntdll!RtlFreeHeap+0x105
02 0833f038 5f98ecfa 00630000 00000000 3b010d70 kernel32!HeapFree+0x14
03 0833f04c 5f992fed 3b010d70 00000004 3b010d70 msvcr120!free+0x1a [f:\dd\vctools\crt\crtw32\heap\free.c @ 51] 
Unable to load image C:\Program Files (x86)\MySQL\Connector ODBC 5.3\myodbc5a.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for myodbc5a.dll
*** ERROR: Module load completed but symbols could not be loaded for myodbc5a.dll
04 0833f0a0 5fa8be41 00000004 07685344 0833f724 msvcr120!setlocale+0xab [f:\dd\vctools\crt\crtw32\misc\setlocal.c @ 51] 
WARNING: Stack unwind information not available. Following frames may be wrong.
05 0833f0cc 5fa8a953 00000001 00000001 00000000 myodbc5a+0x1be41
06 0833f0ec 6559f9c7 26f59008 00000001 0833f724 myodbc5a+0x1a953
07 0833f108 014ac01a 00000000 0833f724 00000001 odbc32!SQLFetch+0x2a4
08 0833f120 014ace64 00000001 00000001 0833f7dc HRDLogbook!CRecordset::FetchData+0x24 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\dbcore.cpp @ 3067] 
09 0833f144 01160090 00000001 00000001 a13bb014 HRDLogbook!CRecordset::Move+0x9c [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\dbcore.cpp @ 1490] 
0a (Inline) -------- -------- -------- -------- HRDLogbook!CRecordset::MoveNext+0x13 [c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\atlmfc\include\afxdb.inl @ 85] 
0b 0833fa80 011a237b 0833faa4 33e43fd8 00000001 HRDLogbook!CBackgroundProcessingThreadLookups::CountryLookup+0x1090 [c:\hrd65\logbook\hrdlogbook\backgroundprocessingthreadlookups.cpp @ 2359] 
0c (Inline) -------- -------- -------- -------- HRDLogbook!CBackgroundProcessingThreadLookups::DoCountryLookup+0x14 [c:\hrd65\logbook\hrdlogbook\backgroundprocessingthreadlookups.cpp @ 276] 
0d (Inline) -------- -------- -------- -------- HRDLogbook!CDXCObject::PerformLookup+0x8c [c:\hrd65\logbook\hrdlogbook\dxclusterobject.cpp @ 1230] 
0e 0833faf4 01998ae0 0633bf40 a13bb1a4 00000000 HRDLogbook!CDXClusterDlg::LookupThreadProc+0x20b [c:\hrd65\logbook\hrdlogbook\dxclusterdlg.cpp @ 352] 
0f (Inline) -------- -------- -------- -------- HRDLogbook!invoke_thread_procedure+0xd [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 
10 0833fb30 7629344d 07665558 0833fb7c 77c89802 HRDLogbook!thread_start<unsigned int (__stdcall*)(void *)>+0x57 [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
11 0833fb3c 77c89802 07665558 7e74c801 00000000 kernel32!BaseThreadInitThunk+0xe
12 0833fb7c 77c897d5 01998a89 07665558 00000000 ntdll!__RtlUserThreadStart+0x70
13 0833fb94 00000000 01998a89 07665558 00000000 ntdll!_RtlUserThreadStart+0x1b



which indicates the customer is using MySQL Version 5.3. We've had plenty of problems with this version of the driver; see Mantis 2732 and 2808 for details.


Because of the similarity to 2732 and 2808, I expect the crash shown in HRDLogbook_20190403_190004.mdmp to be remedied by using a current MySQL ODBC driver.

Because I have no repro steps, and because the thin information given in the description doesn't match the minidumps; and three of the four minidumps are empty files, this issue is somewhere between not repro and won't fix. I think we should have the customer update to a supported, released version of the product, update to a current uspported version of the MySQL drivers, and see how things go.

Issue History

Date Modified Username Field Change
2019-05-06 10:33 KB3NPH New Issue
2019-05-06 10:35 KB3NPH Description Updated View Revisions
2019-05-06 10:41 KB3NPH Description Updated View Revisions
2019-05-06 10:43 KB3NPH Description Updated View Revisions
2019-05-06 14:05 PD9FER Note Added: 0007913
2019-05-06 23:21 K7ZCZ Note Added: 0007916
2019-05-06 23:21 K7ZCZ Assigned To => KB3NPH
2019-05-06 23:21 K7ZCZ Status new => assigned
2019-05-06 23:21 K7ZCZ Status assigned => resolved
2019-05-06 23:21 K7ZCZ Resolution open => unable to reproduce
2019-05-06 23:22 K7ZCZ Relationship added related to 0002732
2019-05-06 23:22 K7ZCZ Relationship added related to 0002808