I have encountered an Unhandled Error Non-UI Thread when starting SSDR this after weeks of successfu

Jack

Recommendation for fixing an UnHandled Error (Non UI Thread) error when attempting to start SSDR ver. 1.3.8.4.7
Weeks of running SSDR successfully and suddenly this error.
Screen scrape of error:

Tim - W4TME

Without seeing the actual detailed information from the Unhandled Exception, we cannot begin to diagnose what actually happened.  Can you post it here?

Jack

Tim - W4TME

Jack - No content in post.

Jack

Sorry it appears that I am unable to paste the screen scrape of the error in this medium. Anyway, I continued to investigate the error employing several Google queries.  Syntax is everything

I found a closed incident reported by NM1W James 9 months ago that seemed to parallel the circumstances I have.

Anyway NM1W reports that he discovered the Flex control was some how involved in his Unhandled Error.

 Well then dawn and lightbulb comes on !

I happened to have just moved the USB plug of my Flex Control to another port on my tower moments before starting up for a day’s run and discovered that the Flex Control nolonger lit up upon starting SSDR. I checked the USB port and it was not a USB 3.0 port so I returned the Flex control to it’s original USB 3.0 port and all is well !

I checked into the MS Technet and discovered thast there is missing code that would have not produced a critical app stopping failure. The Flex Control should simply stopped working not the SSDR app. I received several samples of code that if added to the SSDR app would prevent this hard fail when app launch cannot find the Flex Control. I figured you guys must know this and have a good reason to opt not to include these simple lines of code ??

Now My Flex 6300 is up and running just fine once again ???

Can you shed some light on the reasoning behind not including code to handle the missing Flex Control ?? Also, does moving one’s Flex Control require some sort of reconfiguring this change to the SSDR installation / configuration or was this simply the Flex Control requires USB 3.0 and USB port does not matter ?

I would like to thank you for the prompt response to my post I am so pleased with my new 6300 and to have this kind of access to the people that are directly involved with the product is very reassuring to say the least !!

Sorry for the delay in my response it has been raining in southern Mass and my sump pump died on me which took me away from my new toy 

73 de another happy 6300 owner
W1AKN Jack

Tim - W4TME

Jack - without being able to analyze the unhandled exception code detail, your assumption cannot be verified nor is it known exactly which application actually threw the error.  I move my FlexControl to different USB ports all the time and have never experienced an unhandled exception, so the issue is most likely not systemic in nature.

I suspect what has happened is that when you plugged the FlexControl into another USB port, it was dynamically assigned a different com port number by Windows and that new com port assignment conflicted with an existing virtual com port.  It is the com port conflict that is the trigger of unhandled exception.   A device triggering the event that leads up to an application crashing is not necessarily directly associated with the application that is throwing the error. 

 If a com port conflict is the triggering event, this is due to Windows not properly enumerating the installed virtual com ports (this is a very old Windows problem that has plagued all virtual com port from the dawn of time). Windows thinks a com port is not in use when it really is and assigns it to the FlexControl.  The all %$#* breaks lose.

This is a hard issue to identify and a simple issue to fix.

When the FlexControl is connected to a USB port and it is working, you can open up Device Manager and see what com port it is assigned to.  With SmartSDR and SmartSDR CAT not running, plug the FlexControl into the other USB port and and you will see it appear in Device Manager with a different com port assignment (if you get the unhandled exception, just close it.).  Now at this point you need to manually reassigned the com port assigned to the FlexControl to something that will never conflict with any virtual com ports; I use com port 100.  Here is a HelpCenter article on how to manually change the FlexControl's com port:  http://helpdesk.flexradio.com/hc/en-us/articles/202479329-How-to-Change-the-Com-Port-Assignment-for-...

Once you have done this, reboot the PC for good measure and you should not have any more occurrences of the unhandled exception unless you happen to plug the FlexControl into a different USB port and another conflict arises.

Oh yeah, can you tell Windows is not my favorite operating system :-)