Page 1 of 1
CumulusMX unhandled exception
Posted: Thu 14 Jan 2016 9:18 pm
by cc_rider
Hiya,
Just installed the latest beta3036. Getting some errors on date expectations. Here is screen print with crash..
CCR
Re: CumulusMX unhandled exception
Posted: Thu 14 Jan 2016 9:49 pm
by water01
You need to upload the latest file in MXdiags which will help Steve diagnose the problem.
Re: CumulusMX unhandled exception
Posted: Thu 14 Jan 2016 10:20 pm
by cc_rider
water01 wrote:You need to upload the latest file in MXdiags which will help Steve diagnose the problem.
There are no files in the diags folder.
However, I did find a folder MXdiags, in which there is the following:
20160114-160635.txt
20160114-161144.txt
20160114-171203.txt
The last file is attached.
Re: CumulusMX unhandled exception
Posted: Fri 15 Jan 2016 10:43 am
by steve
I'll need some more information about what you're doing, please. When you say you've installed build 3036, do you mean that you were previously running another build and have upgraded, or have you not had MX running successfully at all?
It look like you are running MX with a copy of your Cumulus 1 data? Is this on the same PC that you were running Cumulus 1?
It looks like Windows is unable to make sense of the timestamp in today.ini, because of you non-standard date format settings. The .Net system routines are apparently unable to parse a date without a year in it, which is understandable. I have changed the code in MX to use an ISO date format in today.ini rather than use the system default (and I'm changing the other ini files in the next build), but it needs to have run successfully once and logged data, to rewrite the today.ini file with the new format.
You could edit today.ini manually before running MX, to change the timestamp line to ISO format. The equivalent of the date shown in your screenshot is:
timestamp=2016-01-14T15:56:00
It's likely that having got past that point, you will have similar issues with timestamps in other ini files such as alltime.ini, so the timestamps for your all-time records will get reset to the current date and time. You could modify those in a similar way to today.ini, but until I release the next build they will probably reset to a format that .Net doesn't understand again anyway even though .Net will have written the dates itself.
Re: CumulusMX unhandled exception
Posted: Fri 15 Jan 2016 8:23 pm
by cc_rider
steve wrote:I'll need some more information about what you're doing, please. When you say you've installed build 3036, do you mean that you were previously running another build and have upgraded, or have you not had MX running successfully at all?
It look like you are running MX with a copy of your Cumulus 1 data? Is this on the same PC that you were running Cumulus 1?
It looks like Windows is unable to make sense of the timestamp in today.ini, because of you non-standard date format settings. The .Net system routines are apparently unable to parse a date without a year in it, which is understandable. I have changed the code in MX to use an ISO date format in today.ini rather than use the system default (and I'm changing the other ini files in the next build), but it needs to have run successfully once and logged data, to rewrite the today.ini file with the new format.
You could edit today.ini manually before running MX, to change the timestamp line to ISO format. The equivalent of the date shown in your screenshot is:
timestamp=2016-01-14T15:56:00
It's likely that having got past that point, you will have similar issues with timestamps in other ini files such as alltime.ini, so the timestamps for your all-time records will get reset to the current date and time. You could modify those in a similar way to today.ini, but until I release the next build they will probably reset to a format that .Net doesn't understand again anyway even though .Net will have written the dates itself.
I installed my first MX into a copy of folder from cumulus 1.94. The old files were still in the folder, and I copied whatever MX had into that folder, possibly over-writing existing files. I noticed a date from 2009 in the log.
Anyway, I have cleared out the MX folder, and placed a fresh copy of the latest MX build 3036 into that folder.
Upon double clicking, I viewed a DOS box. It seems to have initialized and I received a firewall warned for internet access, which I granted. The DOS box reports: Station type not set. Running on port 8998. Lastly to type ctrl-c to terminate. Will attempt to connect with my browser,,, using localhost:8998 Made a connection, which shows three gauges on the dashboard. All values are shown with hyphens. It does not appear to be reading any data, most likely because my ini file is missing from version 1.94?
Replaced the cumulus.ini using the 1.94 version, and restarted cumulusmx. It no shows a connection to the station and showing temp, wind speed/dir etc. Looks like we're cooking with gas now..

Re: CumulusMX unhandled exception
Posted: Fri 15 Jan 2016 8:38 pm
by water01
Double clicking on CumulsMX.exe is the wrong way to start CumulusMX in Windows. You should right click on CumulusMX.exe and select "Run as Administrator" as per the notes.
If you do not start it this way it may fail to write certain files which might explain why your today.ini is not being overwritten.
Re: CumulusMX unhandled exception
Posted: Sat 16 Jan 2016 4:02 am
by cc_rider
water01 wrote:Double clicking on CumulsMX.exe is the wrong way to start CumulusMX in Windows. You should right click on CumulusMX.exe and select "Run as Administrator" as per the notes.
If you do not start it this way it may fail to write certain files which might explain why your today.ini is not being overwritten.
David,
I understand this can happen when the program is installed under c:\program files in windows 8, 8.1 or 10. Just did a quick test, and the ini files in the \data folder are being updated without need for administrator authority.
Now off to resolve other issues..
CCR
Re: CumulusMX unhandled exception
Posted: Sat 16 Jan 2016 7:58 am
by steve
You normally need to run MX as administrator on Windows to allow it to start the http listener on port 8998 for the user interface. The 'netsh' command given in the instructions removes this requirement, so it can then be run without being 'elevated'.