August 22, 20232 yr comment_30377 I've mentioned this one before, where if you export a remote settings, to a OneDrive directory (Microsoft cloud service, that sync's a directory to the cloud and makes it available across any device that you are logged in with), it closes the app. With the new error checking in this version (nice) and it throws an error below. I hope that is as useful as it capturing it. I have tried this on a very early version on a Mac (well when the app worked on that mac), and didn't have any issues. On the windows machine the directory is located in I think the stock location for windows under c:\users\name\OneDrive (where name = logged in users name). In all attempts, a zero length file is written (or overwritten if it already exists after a prompt to confirm). I'll do some more testing and post with any further findings, now we have a way to get errors to see if its the same. Saving to a regular non cloud sync'd (by OneDrive) works fine. System.InvalidCastException: No such interface supported at System.Runtime.InteropServices.McgMarshal.ThrowOnExternalCallFailed(Int32, RuntimeTypeHandle) + 0x21 at __Interop.ComCallHelpers.Call(__ComObject, RuntimeTypeHandle, Int32, Void*) + 0xbe at __Interop.ForwardComStubs.Stub_6[TThis, TArg0](__ComObject, TArg0, Int32) + 0x5a at Windows.Storage.CachedFileManager.DeferUpdates(IStorageFile) + 0x33 at SkipApp.FilePicker.<>c__DisplayClass10_0.<<Save>b__0>d.MoveNext() + 0x4e4 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21 at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__7_0(Object) + 0x1e at System.Action`1.Invoke(T) + 0x28 at System.Threading.WinRTSynchronizationContext.Invoker.InvokeCore() + 0x33 Report
August 24, 20232 yr Author comment_30430 So repeated the test just loaded the app, checked where the logs where, and then did the export. Get this from the new crash system (same I think as before). System.InvalidCastException: No such interface supported at System.Runtime.InteropServices.McgMarshal.ThrowOnExternalCallFailed(Int32, RuntimeTypeHandle) + 0x21 at __Interop.ComCallHelpers.Call(__ComObject, RuntimeTypeHandle, Int32, Void*) + 0xbe at __Interop.ForwardComStubs.Stub_6[TThis, TArg0](__ComObject, TArg0, Int32) + 0x5a at Windows.Storage.CachedFileManager.DeferUpdates(IStorageFile) + 0x33 at SkipApp.FilePicker.<>c__DisplayClass10_0.<<Save>b__0>d.MoveNext() + 0x4e4 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x21 at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<>c.<ThrowAsync>b__7_0(Object) + 0x1e at System.Action`1.Invoke(T) + 0x28 at System.Threading.WinRTSynchronizationContext.Invoker.InvokeCore() + 0x33 --------- and attached is today's logs. If I do this to any other directory (not in the sync) or even another drive its fine. flirc20230824.log Tried this again, but watching the log file, the specific error line to check is: 09:19:18 <4> #ExceptionHandler C:\buildkite-agent\builds\Flirc-Windows-2\flirc-inc\remote-application\desktop\windows\SkipApp\App.xaml.cs:233 Exception caught: No such interface supported Hope that helps Edited August 24, 20232 yr by Jilas671 Report
November 7, 20232 yr Author comment_31618 @jason Hadn't heard anything, so today I randomly unpacked the remotes from their boxes and tried the current beta (0.9.954), and export works, it does what it should, produces a have a file for the remote, and the app doesn't crash anymore. Hopefully this was a planned changed, but seeing things have been quite here, I don't for sure if this is intentional fix or accidental, or even something MS fixed! But providing feedback, just so you are aware something has changed for the better. Report
November 11, 20232 yr comment_31680 On 11/7/2023 at 1:19 AM, Jilas671 said: @jason Hadn't heard anything, so today I randomly unpacked the remotes from their boxes and tried the current beta (0.9.954), and export works, it does what it should, produces a have a file for the remote, and the app doesn't crash anymore. Hopefully this was a planned changed, but seeing things have been quite here, I don't for sure if this is intentional fix or accidental, or even something MS fixed! But providing feedback, just so you are aware something has changed for the better. Awesome. Thanks for letting me know Report
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.