View Issue Details

IDProjectCategoryView StatusLast Update
0002211Ham Radio DeluxeBugpublic2017-09-18 00:08
ReporterKB3NPH 
Assigned ToK7ZCZ 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.787 
Summary0002211: TS-2000 - Immediate RC Crash when starting HRD
DescriptionTicket# 299349
Did a remote with this customer. When connecting to his TS-2000 using an FTDI USB/Serial converter cable. HRD Rig Control immediately crashes after about 3 or 4 seconds. Tested system with Demomatic radio and HRD runs perfectly, it only crashes when attempting to connect to the TS-2000. The Rig Control screen does open and indicates it is connected to the TS-2000, however about 3 to 5 seconds later it crashes with the MFC Error. I installed V6.4.0.664 and everything worked perfectly. This has been happening with this customer for the past 3 or 4 releases where it crashes immediately when starting the TS-2000.

TagsNo tags attached.
ModuleRig Control
Sub-ModuleFunctional
Testing N/A

Relationships

related to 0002202 closedK7ZCZ TS-2000 crashes Rig Controll upons switching between Main and Sub VFO 

Activities

K7ZCZ

2017-08-17 18:50

manager   ~0004012

A minidump would help. Are you able to collect one?

PD9FER

2017-08-19 03:37

viewer   ~0004056

No, not possible.

Got a 2nd ticket from another TS-2000 owner
https://support.ham-radio-deluxe.com/scp/tickets.php?id=11308

PD9FER

2017-09-04 04:18

viewer   ~0004103

Another ticket:
https://support.ham-radio-deluxe.com/scp/tickets.php?id=11553

K7ZCZ

2017-09-04 10:59

manager   ~0004104

I don't believe progress is possible on this issue without access to a TS-2000 to reproduce the crash and debug the code; or a minidump from a customer crash.

PD9FER

2017-09-04 15:23

viewer   ~0004105

https://support.ham-radio-deluxe.com/scp/tickets.php?id=11553
This one I wanted to try a Forced close with build 783 but problem went away by installing it.

PD9FER

2017-09-05 10:36

viewer  

HamRadioDeluxe_20170905_152837.zip (3,717,376 bytes)

PD9FER

2017-09-05 10:36

viewer   ~0004110

Minidump added.

K7ZCZ

2017-09-05 11:57

manager   ~0004111

The 20170905_152837 minidump above yields this callstack, which unfortunately isn't too useful. For now, all I've got is that some string formatting call is getting sick -- but I can't tell which one (there are zillions) or what specifically is going wrong.

     KERNELBASE.dll!_RaiseException@16() Unknown
> HamRadioDeluxe.exe!_vswprintf_helper(int (_iobuf *, const wchar_t *, localeinfo_struct *, char *) * woutfn=0x0538e9a0, unsigned short * string=0x0155b7c4, unsigned int count=276230788, const wchar_t * format=0x002d0000, localeinfo_struct * plocinfo=0x002d0240, char * ap=0x00000002) Line 157 C

It does tell us that we're crashing when trying to format a string with sprintf (or one of its friends). The referenced format string is empty:

0x002D0000 00 00 00 00 90 aa 9b 00 08 e0 aa 00 00 00 9b 00 58 2c 2d 00 00 30 2d 00 00 e0 2d 00 7d 0f 00 00 56 0d 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00

the count looks pretty much invalid (way too big) and the string parameter points at another empty string:

0x0155B7C4 00 00 00 00 c5 f1 31 01 00 00 00 00 d4 b7 55 01 03 00 00 00 e4 b7 55 01 6c b7 55 01 24 f5 53 01 00 00 00 00 64 54 57 01 00 00 00 00 ff ff ff ff 00 00 00 00 0c 00 00

When the call stack is munged like this, it means we've either painted over it with bad code, or we've lost the chain of frames because of the structure of the involved calls.

Maybe another minidump gives me better luck, so please keep them coming. Meanwhile, I can dig into this dump with windbg (instead of Visual Studio) and I might be able to extract more information.

PD9FER

2017-09-05 16:09

viewer   ~0004112

Minidump from the origin report owner here...

HamRadioDeluxe_20170905_210106.zip (3,823,193 bytes)

K7ZCZ

2017-09-05 17:45

manager   ~0004113

the second minidump has a stack that's more helpful, but not completely revealing. It's missing at least a few frames; there's no call directly from CThinThread::Run() and ATL::SimpleStringT::Reallocate(). It's pretty clear the problem is the reallocation length (if that value is to be trusted) is more than a gigabyte and a half: Reallocate(int nLength=1,537,535,203)

Almost anything can be in play: thread race to the same string, bad data, bad format string, and so on.

The exception message in this second mindump is here:

Unhandled exception at 0x7504B802 in HamRadioDeluxe_20170905_210106.mdmp: Microsoft C++ exception: std::out_of_range at memory location 0x098EF744.

And the stack trace is here:


     KERNELBASE.dll!_RaiseException@16() Unknown
     HamRadioDeluxe.exe!_vswprintf_helper(int (_iobuf *, const wchar_t *, localeinfo_struct *, char *) * woutfn=0x094eec10, unsigned short * string=0x0177b7c4, unsigned int count=160364356, const wchar_t * format=0x00360240, localeinfo_struct * plocinfo=0x00000005, char * ap=0x00360000) Line 157 C
     04a48908() Unknown
     [Frames below may be incorrect and/or missing]
> HamRadioDeluxe.exe!ATL::CSimpleStringT<wchar_t,0>::Reallocate(int nLength=1537535203) Line 859 C++
     HamRadioDeluxe.exe!CThinThread::Run() Line 143 C++
     HamRadioDeluxe.exe!CThinThread::Start(void * pv=0x017a2020) Line 191 C++
     HamRadioDeluxe.exe!_callthreadstartex() Line 376 C
     HamRadioDeluxe.exe!_threadstartex(void * ptd) Line 354 C
     kernel32.dll!@BaseThreadInitThunk@12() Unknown
     ntdll.dll!__RtlUserThreadStart() Unknown
     ntdll.dll!__RtlUserThreadStart@8() Unknown

K7ZCZ

2017-09-05 17:51

manager   ~0004114

At least some trouble from diagnosing this issue comes from the errant programming practice of swallowing exceptions in our code.

The implementation of CThinThread::Start() is shown below. It includes an empty CATCH block which swallows any CException-derived exception "just in case".

Mantis 2046 tracks the removal of such code.

unsigned int __stdcall CThinThread::Start(void* pv)
{
    CThinThread* pMT = static_cast<CThinThread*> (pv);

    TRY
    {
        pMT->Run();
    }

    CATCH (CException, ex)
    {
        //
        // Just in case - no action taken.
        //
    }
    END_CATCH

    //
    // Return.
    //
    return 0;
}

K7ZCZ

2017-09-05 18:48

manager   ~0004115

Ok, got a clean stack out of WinDBG for the second dump, so here it is:


Microsoft (R) Windows Debugger Version 10.0.15063.468 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\dumps\Mantis2211\HamRadioDeluxe_20170905_210106.mdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: srv*
Executable search path is:
Windows 10 Version 15063 MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
10.0.15063.0 (WinBuild.160101.0800)
Machine Name:
Debug session time: Tue Sep 5 14:01:06.000 2017 (UTC - 7:00)
System Uptime: not available
Process Uptime: 0 days 0:00:02.000
................................................................
..............................................
Loading unloaded module list
.
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(2c24.21c0): C++ EH exception - code e06d7363 (first/second chance not available)
eax=00000000 ebx=0a003fa0 ecx=00000003 edx=00000000 esi=0a003f58 edi=0a003f68
eip=77ce2bac esp=098ed71c ebp=098ed728 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
ntdll!NtGetContextThread+0xc:
77ce2bac c20800 ret 8
0:013> .ecxr
*** WARNING: Unable to verify checksum for HamRadioDeluxe.exe
eax=098ef698 ebx=098ef878 ecx=00000003 edx=00000000 esi=0177b7c4 edi=098ef744
eip=7504b802 esp=098ef698 ebp=098ef6f4 iopl=0 nv up ei pl nz ac po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000212
KERNELBASE!RaiseException+0x62:
7504b802 8b4c2454 mov ecx,dword ptr [esp+54h] ss:002b:098ef6ec=60704959
0:013> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr Args to Child
00 098ef6f4 012fc4ae e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x62
01 098ef734 0153f29a 098ef744 0177b7c4 01626370 HamRadioDeluxe!_CxxThrowException+0x5b [f:\dd\vctools\crt\crtw32\eh\throw.cpp @ 152]
02 098ef750 01146dcf 016e6b3c 5ba4e74b 04bf47b8 HamRadioDeluxe!std::_Xout_of_range+0x2d [f:\dd\vctools\crt\crtw32\stdcpp\xthrow.cpp @ 24]
03 098ef7a4 0112ada7 098ef878 098efbb4 00000000 HamRadioDeluxe!CRadioOptions::LookupCTCSS+0x18f [c:\ham radio\hamradiodeluxe\radiooptionsctcss.cpp @ 196]
04 098efb30 01165057 098efbb4 00b3e9d0 094ef250 HamRadioDeluxe!CRadioOptions::StatusTexts+0x33a7 [c:\ham radio\hamradiodeluxe\radiooptions.cpp @ 18842]
05 098efb80 0103aab6 00000017 5ba4eb0b 012fb8f6 HamRadioDeluxe!CRefreshData::Go+0x5d7 [c:\ham radio\hamradiodeluxe\refreshdata.cpp @ 646]
06 098efbe4 01193e90 5ba4ece3 04b9e468 00a95698 HamRadioDeluxe!CBackgroundProcessingThread::DoWork+0xd6 [c:\ham radio\hamradiodeluxe\backgroundprocessingthread.cpp @ 176]
07 098efc0c 01193f26 5ba4ecaf 012fb8f6 04b9e468 HamRadioDeluxe!CThinThread::Run+0x70 [c:\ham radio\hamradiodeluxe\thinthread.cpp @ 143]
08 098efc40 012fb84a 017a2020 5ba4ec97 012fb8f6 HamRadioDeluxe!CThinThread::Start+0x46 [c:\ham radio\hamradiodeluxe\thinthread.cpp @ 191]
09 098efc78 012fb972 012fb8f6 098efc98 753c8744 HamRadioDeluxe!_callthreadstartex+0x1b [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376]
0a 098efc84 753c8744 04b9e468 753c8720 b49a97c7 HamRadioDeluxe!_threadstartex+0x7c [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354]
0b 098efc98 77cd582d 04b9e468 edb4d685 00000000 kernel32!BaseThreadInitThunk+0x24
0c 098efce0 77cd57fd ffffffff 77cf6389 00000000 ntdll!__RtlUserThreadStart+0x2f
0d 098efcf0 00000000 012fb8f6 04b9e468 00000000 ntdll!_RtlUserThreadStart+0x1b

K7ZCZ

2017-09-06 01:05

manager   ~0004116

I goofed-up building the map of radios to CTCSS frequency lists such that the RX and TX lists were the same. Which is bad, because the TX list might/does have an extra 1750 Hz entry on the end of it. If the radio was set for this TX tone, then we'd walk off the end of the vector associated with the radio and crash. Pretty subtle, a lot easier to find with the minidumps so thanks for posting them!!1!

Fixed in this change set.
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/3831

PD9FER

2017-09-08 05:11

viewer   ~0004142

Have installed it with one customer
All seems to be working fine

PD9FER

2017-09-08 09:51

viewer   ~0004144

100% fix confirmed after installing at the other customers PC.
Thanks!

WA9PIE

2017-09-18 00:08

administrator   ~0004212

Closed as part of the 6.4.0.787 release.

Issue History

Date Modified Username Field Change
2017-08-16 12:38 KB3NPH New Issue
2017-08-17 18:50 K7ZCZ Assigned To => K7ZCZ
2017-08-17 18:50 K7ZCZ Status new => feedback
2017-08-17 18:50 K7ZCZ Note Added: 0004012
2017-08-17 18:52 K7ZCZ Assigned To K7ZCZ => KB3NPH
2017-08-19 03:37 PD9FER Note Added: 0004056
2017-09-04 04:18 PD9FER Note Added: 0004103
2017-09-04 10:59 K7ZCZ Note Added: 0004104
2017-09-04 15:23 PD9FER Note Added: 0004105
2017-09-05 10:36 PD9FER File Added: HamRadioDeluxe_20170905_152837.zip
2017-09-05 10:36 PD9FER Note Added: 0004110
2017-09-05 10:51 K7ZCZ Assigned To KB3NPH => K7ZCZ
2017-09-05 10:51 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2017-09-05 11:57 K7ZCZ Note Added: 0004111
2017-09-05 16:09 PD9FER File Added: HamRadioDeluxe_20170905_210106.zip
2017-09-05 16:09 PD9FER Note Added: 0004112
2017-09-05 17:45 K7ZCZ Note Added: 0004113
2017-09-05 17:51 K7ZCZ Note Added: 0004114
2017-09-05 18:48 K7ZCZ Note Added: 0004115
2017-09-06 01:05 K7ZCZ Status feedback => resolved
2017-09-06 01:05 K7ZCZ Resolution open => fixed
2017-09-06 01:05 K7ZCZ Note Added: 0004116
2017-09-06 01:15 K7ZCZ Relationship added related to 0002202
2017-09-07 18:18 K7ZCZ Fixed in Version => 6.4.0.784
2017-09-08 05:11 PD9FER Note Added: 0004142
2017-09-08 09:51 PD9FER Note Added: 0004144
2017-09-11 21:32 K7ZCZ Fixed in Version 6.4.0.784 => 6.4.0.785
2017-09-14 19:23 K7ZCZ Fixed in Version 6.4.0.785 => 6.4.0.787
2017-09-18 00:06 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2017-09-18 00:08 WA9PIE Note Added: 0004212
2017-09-18 00:08 WA9PIE Status resolved => closed