View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003310||4 - Closed w/o Action||Bug||public||2019-05-06 10:33||2019-05-27 15:03|
|Status||closed||Resolution||unable to reproduce|
|Summary||0003310: V126.96.36.199 crashing when Logbook closes|
|Description||This 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.
|Tags||No tags attached.|
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?
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: 188.8.131.52 Product version: 184.108.40.206 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 220.127.116.11, 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.
|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|
|2019-05-27 15:02||WA9PIE||Project||1 - Backlog => 4 - Closed w/o Action|
|2019-05-27 15:03||WA9PIE||Status||resolved => closed|