View Issue Details

IDProjectCategoryView StatusLast Update
0002990Ham Radio DeluxeBugpublic2019-01-16 22:04
Reporterw4elp 
Assigned ToK7ZCZ 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformPCOSWin 10OS Version1803
Product Version 
Target VersionFixed in Version6.5.0.183 
Summary0002990: Selecting Demomatic radio causes DM780 crash
DescriptionIf any Demomatic radio (except TS-590) is selected and connected in Rig Control, DM780 will shut down without warning and without creating a minidump.
Steps To Reproduce1. Run Rig Control and DM780 with a working "real" radio.
2. In Rig Control, hit File > Disconnect. (This step can be skipped - doesn't seem to matter)
3. Hit CONNECT and select any Demomatic radio except TS-590.
4. If DM780 is still running, confirm that it recognizes the Demomatic radio. If not, try to connect in DM780 Radio pane.
At this point, DM780 will usually have crashed.
Additional InformationThis bug is only in v6.5.0.133. 6.5.0.132 is ok except for the Orion failure to connect.
Restoring Rig Control to the original "real" radio does not always restore proper DM780 operation.
TagsNo tags attached.
ModuleRig Control
Sub-ModuleRig Control
Testing Beta Successful

Relationships

Activities

g3ucq

2018-12-14 09:13

viewer   ~0006633

I confirm Ed's findings above.
Now I am finding that DM780 connects to the correct radio and after a few seconds suddenly closes.
I have not touched any keys or buttons for this to happen.
No mini dump file is created.

g3ucq

2018-12-14 11:56

viewer   ~0006641

I have reverted to v6.5.0.132 and that gives no problems for me.

K7ZCZ

2018-12-14 14:57

manager   ~0006649

Not sure why this is in the "Issues Needing Retest" project. I don't normally look here for new Mantis issues, and I don't have rights in Mantis to move this issue to a more appropriate project. I also didn't know we released build 133.

Meanwhile, I'll have a look ... I guess I'll try to bookmark this issue so I don't lose it.

w4elp

2018-12-14 15:43

viewer   ~0006650

Sorry for the incorrect project classification. Seemed like the issue of Demomatic radios needed retesting. For future reference, what would have been correct classification?

K7ZCZ

2018-12-14 16:32

manager   ~0006651

So far, I am unable to reproduce this issue. Any clues or a minidump would be welcome. Remember that you can configure Windows Error Reporting to collect dumps that HRD itself doesn't catch.

g3ucq

2018-12-15 04:13

viewer   ~0006653

Mike. Error reporting produced this.

Source
Digital Master 780

Summary
Stopped working

Date
‎15/‎12/‎2018 09:57

Status
Report sent

Description
Faulting Application Path: C:\Program Files (x86)\HRD Software LLC\Ham Radio Deluxe\Digital Master.exe

Problem signature
Problem Event Name: APPCRASH
Application Name: Digital Master.exe
Application Version: 6.5.0.133
Application Timestamp: 5c113ae0
Fault Module Name: StackHash_59ff
Fault Module Version: 10.0.17134.471
Fault Module Timestamp: fe852bc4
Exception Code: c0000374
Exception Offset: PCH_D2_FROM_ntdll+0x0006AE8C
OS Version: 10.0.17134.2.0.0.768.101
Locale ID: 2057
Additional Information 1: 59ff
Additional Information 2: 59ffa068ead3d1f7c935aab0859015a6
Additional Information 3: afac
Additional Information 4: afac038e20407924202d666d0aa9778f

Extra information about the problem
Bucket ID: 2e617eccd1df0e6715d340510758b308 (1572671411642217224)

HTH.

K7ZCZ

2018-12-15 10:20

manager   ~0006656

This is just a summary report, not a minidump. The minidump itself is required in order to make progress with investigation.

The "Collecting User-Mode Dumps" article at the Microsoft site (https://docs.microsoft.com/en-us/windows/desktop/wer/collecting-user-mode-dumps) has instructions for making a couple of registry settings that will keep the dump that Windows generates. Normally, it's generated, sent off to Microsoft, then deleted. If it's kept, then the file can be retrieved and provided here.

w4elp

2018-12-15 14:36

viewer   ~0006664

Digital Master.exe.536.dmp added to Dropbox. Mike, you can delete after downloading.
Ed - W4ELP

K7ZCZ

2018-12-15 16:03

manager   ~0006665

Thanks for the dump! That makes finding the problem a snap. Looks like the crash is actually in the HRDLogbookInterface code. Was the Logbook also involved in this problem?

The app uses XML all over the place, even sometimes when it shouldn't. There's some common code to facilitate building and parsing XML documents. That code mostly works, but has a few problems ... one of which is memory management. I've been trying to clean things up, and it looks like I goofed; I free memory twice in some cases.

Here's the call stack from the dump:

0:014> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
00 0af9b00c 773816c0 00000001 00000008 7737f5cf ntdll!RtlReportCriticalFailure+0x88
01 0af9b018 7737f5cf 7003e11f 0b428270 0e062510 ntdll!RtlpReportHeapFailure+0x2f
02 0af9b04c 77389e6e 0e062510 02cc0000 00000008 ntdll!RtlpHpHeapHandleError+0x6e
03 0af9b060 773203ce 0e062510 00000000 00000000 ntdll!RtlpLogHeapFailure+0x41
04 0af9b08c 73cb251b 02cc0000 00000000 0e062518 ntdll!RtlSizeHeap+0x51ffe
05 0af9b0a0 7457d6b1 73dbc100 0e062518 00000001 combase!CRetailMalloc_GetSize+0x1b [onecore\com\combase\class\memapi.cxx @ 702] 
06 0af9b0c8 7457d60d 0e062518 02cc00d0 0759db94 oleaut32!APP_DATA::FreeCachedMem+0x41
07 0af9b0e4 65694ca5 0e06251c 62b8b21b 04caa948 oleaut32!SysFreeString+0x4d
08 (Inline) -------- -------- -------- -------- HRDLogbookInterface!ATL::CComBSTR::{dtor}+0x5 [c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\atlmfc\include\atlcomcli.h @ 1672] 
09 0af9b12c 65694ada 098d71b0 0af9b1bc 0af9b1c0 HRDLogbookInterface!CXMLMgr::GetNamedItem+0x1a5 [c:\hrd65\hrdcommon\xmlmgr.cpp @ 2341] 
0a 0af9b158 65690381 0af9b1c0 098d71b0 0af9b1bc HRDLogbookInterface!CXMLMgr::GetNamedItem+0x6a [c:\hrd65\hrdcommon\xmlmgr.cpp @ 2082] 
0b 0af9b1d4 6568d31a 0af9b230 65834d74 0af9b210 HRDLogbookInterface!CHRDLogbookInterfaceApp::GetXMLValue+0x1d1 [c:\hrd65\logbook\hrdlogbookinterface\hrdlogbookxml.cpp @ 169] 
0c 0af9b240 00e0ac75 0b8be800 066e23c1 01800480 HRDLogbookInterface!HRDLogbookInterfaceCallsignsWorkedByBand+0x3ca [c:\hrd65\logbook\hrdlogbookinterface\hrdlogbookdefines.cpp @ 588] 
0d 0af9b6d0 00e0cefe 066e6279 0b3ee518 01800480 Digital_Master!CBackgroundProcessingThread::LogbookCommand+0x905 [c:\hrd65\digital master\digital master\backgroundprocessingthreadlog.cpp @ 253] 
0e 0af9f768 00e0be11 0b3ee518 066e628d 0b3ad368 Digital_Master!CBackgroundProcessingThread::ProcessData+0x109e [c:\hrd65\digital master\digital master\backgroundprocessingthreadpacket.cpp @ 1700] 
0f 0af9f79c 00fae21b 066e62cd 0b3ad368 00fae180 Digital_Master!CBackgroundProcessingThread::DoWork+0xd1 [c:\hrd65\digital master\digital master\backgroundprocessingthreadpacket.cpp @ 1069] 
10 (Inline) -------- -------- -------- -------- Digital_Master!CThinThread::Run+0x5a [c:\hrd65\digital master\digital master\thinthread.cpp @ 182] 
11 0af9f7dc 00ff0dc3 01800480 066e6d81 0758ac68 Digital_Master!CThinThread::Start+0x9b [c:\hrd65\digital master\digital master\thinthread.cpp @ 225] 
12 0af9f890 013802fc 00afe3b4 066e6ddd 013802a4 Digital_Master!_AfxThreadEntry+0xfe [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 109] 
13 (Inline) -------- -------- -------- -------- Digital_Master!invoke_thread_procedure+0xd [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 
14 0af9f8cc 743c8484 0758ac68 743c8460 737e4d3a Digital_Master!thread_start<unsigned int (__stdcall*)(void *)>+0x58 [minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
15 0af9f8e0 77303ab8 0758ac68 7003a87b 00000000 kernel32!BaseThreadInitThunk+0x24
16 0af9f928 77303a88 ffffffff 7731f302 00000000 ntdll!__RtlUserThreadStart+0x2f
17 0af9f938 00000000 013802a4 0758ac68 00000000 ntdll!_RtlUserThreadStart+0x1b


That function mixes _bstr_t and CComBSTR, and they fight over releasing the involved memory, but there can only be one.

K7ZCZ

2018-12-15 16:15

manager   ~0006666

Fixed with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4571

w4elp

2018-12-15 17:12

viewer   ~0006667

Logbook did not crash, but would have to be manually reconnected in its radio pane after each new Demomatic selected in Rig Control. Otherwise LB would continue to display the last frequency when it was connected.

g3ucq

2018-12-16 04:46

viewer   ~0006670

On opening DM780 it freezes i.e no action from the waterfall, and after a few seconds closes with no action on my part.
Dump file attached. HTH

g3ucq

2018-12-16 04:49

viewer   ~0006671

Sorry. The file is too large so have added it to Dropbox\Ham Radio Deluxe (1)\HRD Beta Team.

w4elp

2018-12-16 17:34

viewer   ~0006678

Found that simply doing a File > Restart on Rig Control eventually crashes DM780. After Rig Control restart, DM780 fails to reconnect and crashes when manually connecting.
So perhaps this bug is not related to the Demomatic radios but to the act of disconnecting Rig Control from the radio and reconnecting.

K7ZCZ

2018-12-16 18:18

manager   ~0006679

Several different crashes have been reported, but I've only fixed one -- the one that had a dump file.

If you are finding other ways to crash the application, please open a new issue and attach a dump file matching the crash steps.

w4elp

2018-12-16 20:20

viewer   ~0006680

Not finding new ways to crash it - just an abbreviated version of the same thing. I'll wait for a release that fixes this Mantis issue then see if additional Mantis issues are warranted.

w4elp

2018-12-17 05:44

viewer   ~0006684

Resolved in v6.5.0.157.
No DM780 crash when connecting to different radio or Demomatic.

K7ZCZ

2018-12-17 05:57

manager   ~0006685

Thanks. What about when doing a "Restart" on Rig Control?

g3ucq

2018-12-17 06:04

viewer   ~0006686

Fixed in v6.5.0.157

w4elp

2018-12-17 06:41

viewer   ~0006688

Rig Control restart no longer crashes DM780 either. Think it was all related to disconnecting the radio. Once disconnected, DM780 would crash when trying to reconnect. Thanks, Mike.

g3ypp

2018-12-18 05:15

viewer   ~0006701

This problem does not occur for me in .157

Issue History

Date Modified Username Field Change
2018-12-14 05:03 w4elp New Issue
2018-12-14 09:13 g3ucq Note Added: 0006633
2018-12-14 11:56 g3ucq Note Added: 0006641
2018-12-14 14:57 K7ZCZ Note Added: 0006649
2018-12-14 15:43 w4elp Note Added: 0006650
2018-12-14 16:32 K7ZCZ Note Added: 0006651
2018-12-15 04:13 g3ucq Note Added: 0006653
2018-12-15 10:20 K7ZCZ Note Added: 0006656
2018-12-15 14:36 w4elp Note Added: 0006664
2018-12-15 16:03 K7ZCZ Note Added: 0006665
2018-12-15 16:15 K7ZCZ Assigned To => K7ZCZ
2018-12-15 16:15 K7ZCZ Status new => resolved
2018-12-15 16:15 K7ZCZ Resolution open => fixed
2018-12-15 16:15 K7ZCZ Note Added: 0006666
2018-12-15 17:12 w4elp Note Added: 0006667
2018-12-16 04:46 g3ucq Note Added: 0006670
2018-12-16 04:49 g3ucq Note Added: 0006671
2018-12-16 17:34 w4elp Note Added: 0006678
2018-12-16 18:18 K7ZCZ Note Added: 0006679
2018-12-16 20:20 w4elp Note Added: 0006680
2018-12-17 02:57 WA9PIE Project Issues Needing Retest => 3 - Current Dev List
2018-12-17 05:44 w4elp Note Added: 0006684
2018-12-17 05:57 K7ZCZ Note Added: 0006685
2018-12-17 06:04 g3ucq Note Added: 0006686
2018-12-17 06:41 w4elp Note Added: 0006688
2018-12-17 14:46 K7ZCZ Fixed in Version => 6.5.0.157
2018-12-18 05:15 g3ypp Note Added: 0006701
2018-12-20 22:31 WA9PIE Status resolved => closed
2018-12-20 22:31 WA9PIE Testing Not Started => Beta Successful
2019-01-16 22:04 WA9PIE Fixed in Version 6.5.0.157 => 6.5.0.183
2019-01-16 22:04 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe