CumulusMX unhandled exception

[cc_rider]

Hiya,
Just installed the latest beta3036. Getting some errors on date expectations. Here is screen print with crash..

CCR

[water01]

You need to upload the latest file in MXdiags which will help Steve diagnose the problem.

[cc_rider]

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.

[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.

[cc_rider]

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..

[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.

[cc_rider]

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

[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'.