Crash report from the Microsoft Store

[m1l]

Hi, I have deployed application to Microsoft Store using 0.1.6-Alpha2 of direcorywatcher due to that Access Violation error from 0.1.6. and I am not sure if these errors are debuggable as this is the only thing Microsoft Store gives me in Stack Trace from unknown users: clr_exception_system.runtime.interopservices.sehexception_80004005_myoddweb.directorywatcher.interop.x64.dll!unknown

Frame | Image | Function | Offset
0 | myoddweb.directorywatcher.interop.x64.dll | Unknown | 0x0000000000000001
1 | myoddweb.directorywatcher.interop.x64.dll | Unknown | 0x0000000000000085
2 | myoddweb.directorywatcher.interop.x64.dll | Unknown | 0x00000000000000D5
3 | myoddweb.directorywatcher.interop.x64.dll | Unknown | 0x0000000000000018

and another report fail_fast_invalid_balanced_tree_c0000409_myoddweb.directorywatcher.win.x64.dll!unknown

Frame | Image | Function | Offset

0 | ntdll.dll | RtlRbRemoveNode | 0x00000000000008EA
1 | ntdll.dll | RtlpHpVsChunkSplit | 0x0000000000000042
2 | ntdll.dll | RtlpHpVsContextAllocateInternal | 0x00000000000001DB
3 | ntdll.dll | RtlpAllocateHeapInternal | 0x0000000000000767
4 | ntdll.dll | RtlpHpAllocWithExceptionProtection | 0x000000000000001C
5 | ucrtbase.dll | _malloc_base | 0x0000000000000036
6 | myoddweb.directorywatcher.win.x64.dll |   | 0x000000000000B85B

Then another one submitted by the program itself:

System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.Runtime.InteropServices.SEHException: Eine externe Komponente hat eine Ausnahme ausgelöst.
   bei _CxxThrowException(Void* , _s__ThrowInfo* )
   bei Watcher1.{ctor}(Watcher1* )
   bei Importer(UInt32 id)
   bei myoddweb.directorywatcher.Interop.Watcher..ctor()
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
   bei System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   bei System.Activator.CreateInstance(Type type, Boolean nonPublic)
   bei System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   bei System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   bei System.Reflection.Assembly.CreateInstance(String typeName, Boolean ignoreCase, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   bei myoddweb.directorywatcher.utils.TypeLoader.LoadTypeFromAssembly[T](Assembly assembly)
   bei myoddweb.directorywatcher.utils.TypeLoader.LoadTypeFromAssembly[T](String assemblyFilePath)
   bei myoddweb.directorywatcher.utils.WatcherManager.CreateWatcherFromFileSystem()
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei myoddweb.directorywatcher.utils.WatcherManager.CreateWatcherFromFileSystem()
   bei myoddweb.directorywatcher.Watcher..ctor()
   bei Rapidrive.FSWNEW..ctor()
   bei Rapidrive.FFControl.SetWatchState(Boolean b)

The last function does:
 if (fsw==null)
   fsw = new FSW();
else 
   fsw.Stop();
...
fsw contains:
watcher.Add(new Request(inputPath, true));
watcher.OnAddedAsync += Watcher_OnAddedAsync;
watcher.OnRemovedAsync += Watcher_OnRemovedAsync;
watcher.Start();

Since all this anonymous, I cannot reach out and find out how did the issue happen, what kind of directory user tried to access or anything else.

Program is at OCv2.com and function is now in there as experimental replacement for .net filesystemwatcher in Settings>Experimental option

[FFMG]

Hi, it took me a bit of time ... but I think I found the issue.

Are you able to reproduce it?

If you can, maybe I can upload another alpha release.

[FFMG]

Hi,

Can you please try

update-package MyOddWeb.DirectoryWatcher -Version 0.1.7-alpha1

I think it addresses the crash issue although I have not been able to reproduce the exact same scenario, (but the Rtl* messages were the same).

Thanks

[FFMG]

Duplicate of #6

[m1l]

I could not reproduce the posted errors myself and I don't know under which conditions they happen. On Monday I'll update to 0.1.7-alpha1 and test it for some time, then if everything works for me, I can push the update to the Store with gradual rollout and see if there are more crashes with that message. I'll also wrap it in try/catch and prompt user to describe situation how it happened (although that part rarely results in useful info, it at all). Thank you for the update!

[FFMG]

I think this was fixed in 0.1.7

Let me know if you can reproduce it, and please include a sample app, it is almost impossible to test without a proper sample/case to look at.

[m1l]

Only today the program passed certification with 0.1.7-alpha1 included and if there are issues I will get the crash reports soon. I'll start working on update and include 0.1.7 while developing and keep you posted on potential issues. Thank you

[m1l]

Update: I still get these reports in the Store:

invalid_pointer_read_iid_iunknown_c0000005_atidxx64.dll!xdxquerytlslookuptable and null_pointer_write_c0000005_myoddweb.directorywatcher.win.x64.dll!unknown but this is the 0.1.7-alpha1. Do you already know if this is fixed in latest version

[FFMG]

Hi, As you can appreciate, this is extremely hard to even start investigate something like that. Ideally we would have, at least, some steps to reproduce this issue, (what was happening at the time and so on). I don't even know what the code was doing at the time, starting? stopping? adding a folder? removing a folder? was an error thrown? any other logs?

I will keep looking at it, but to be honest, with the info you gave me, I have little to work on.

[m1l]

I assumed it is so, but wanted to share just in case you recognized what might be wrong. Unfortunately the store removes the pdb so that is all I get. I will let you know as soon as I have any more information. Thanks

[FFMG]

I am running some tests here without any issues :(. Can you give me a break down of what your app does so I can load test it.

What I have done is

1. Create a Watcher
2. Add a couple of events, (Add/Delete/Update), and log to console
3. Add a couple of folders
4. Wait for an event
5. Randomly stop watching a folder
6. Randomly add another folder

I do the above a few million times, (literally), without any issues.

Maybe your app does something slightly differently? Maybe add/remove watchers? Call dispose directly .... anything different

Maybe I will upload that app and you can also run it and see if you manage to get any sort of error.

[m1l]

I myself cannot reproduce the issue on any of PCs I use, so it is only happening for random users. But after several days on the Store, I now have more data for this, and there were 18 sessions with these crashes compared to 2500 sessions for the same version. Now that is only for users that have enabled the watcher (by default program still uses .NET FileSystemWatcher) and from the people who enabled these reports in Windows. That is also for 0.1.7-Alpha1, and in a few days I'll post update with 0.1.7. I am not sure if it may be affected, but users could be also using it on folders with paths that have unsupported characters for Windows OS, or paths with more 255 characters, cloud folders that may not be synchronized yet, HFS+ partitions with a 3rd party driver that enables reading those, and other paths we cannot think of.

I do remove UserControls that have the watcher when user closes a panel, and this is the cleanup on _Unloaded event

void FolderListBox_Unloaded(object sender, RoutedEventArgs e)
{
 if (watcher != null)
 {
   watcher.Stop();
   watcher.OnAddedAsync -= Watcher_OnAddedAsync;
   watcher.OnRemovedAsync -= Watcher_OnRemovedAsync;
   watcher.OnRenamedAsync -= Watcher_OnRenamedAsync;