https://bugs.winehq.org/show_bug.cgi?id=52131
--- Comment #16 from Eric eric.wheez@gmail.com --- Created attachment 71214 --> https://bugs.winehq.org/attachment.cgi?id=71214 Analysis of crashing vs working gridsquares given to PropagationPrediction.dll/dvoa.dll
It looks like the crashing gridsquares all have a returning value of `"Freqs": [ 0.01]` but the working gridsquares have a returning value of "Freqs" with other values. Here's an example with oversimplified text:
--Working-- ENTER:c ([STRING:030c77c0:IM59NE], 3610.100000, [:031aee58]) LEAVE:c ([STRING:03000760:{"Arguments": {"RxLocations": [{"Lat": 39.19, "Lon": -8.88, "Freqs": [ 3.61] --------
--Crashing-- ENTER:c ([STRING:03249260:AE01UB], 7.093000, [:03249058]) LEAVE:c ([STRING:0324ba20:{"Arguments": {"RxLocations": [{"Lat": -48.94, "Lon": -178.29, "Freqs": [ 0.01] --------
RMS Channels.dat CT1CPS|IM59NE|3610100|13|00-23|PUBLIC <-- working CT1CPS|IM59NE|3610100|50|00-23|PUBLIC <-- working DA5UDI|JO30QJ|7051400|43|00-23|PUBLIC <-- working 9W2RUT|AE01UB|7093|41|00-23|PUBLIC <-- crashes 9W2RUT|OJ02UX|7093|41|00-23|PUBLIC <-- crashes | | | | | |__HF frequency to calculate propagation qualty for | | | |__Gridsquare (geographical location) | |__Callsign (person)
I'm attaching more examples of this kind of analysis with oversimplified strings for easier comparison (I just found/replaced a lot of the parts that were the same between all the strings so things would be easier to read)
So, now I'm thinking that it may not be the Lat/Long input, but the frequency input that is the issue. I think the PropagationPrediction.PredictionClass:CreateDVOACapQuery method may be garbling just some of the input frequency strings that are supposed be sent to dvoa.dll (I believe dvoa.dll is run during the LoadDll method) and then dvoa.dll is reporting an error with 0x0eedfade. I'm not sure why only some smaller-value frequencies would cause issues, but I'll keep digging.