Icaros cache with non-local account 0x14 error

[funky-d]

Hi Xanashi,

I mentioned this issue in the Shark007 forums when using a non-local Windows account (in my case, a domain account, but it may also happen when using a Microsoft account to log into Windows). While Icaros appears to successfully build a cache according to the graph on the cache page of the config program, it is unable to clear the cache or build/rebuild the cache when locations are set. The rebuild button results in a 0x14 error, while the clear cache button prompts with the warning but does not clear the cache after clicking "Yes".

On my system, I have the location pointed to a local test directory with a handful of movies. My domain account, the local administrators group, and system all have full access to this location, as well as the Icaros cache location. My domain account is a local admin account on my computer. I tried loading one of the movies into the debug section of Icaros. Thumbnailing via Icaros gives a time of 81.72ms but the "From Cache" column says "No." Thumbnailing via Explorer gives a time of 9.74ms and "Icaros Thumbnail Provider" for the shell extension. Does this indicate its using Windows for the thumbnail cache?

If there is any other testing I can perform, please let me know! Thank you for looking into this.

[Xanashi]

Hi funky-d,

Thanks for following up in here.

Could you please try this test build and see if it helps:
https://www.mediafire.com/file/ji3skjlc7cal1q5/Icaros_v3.3.0_0x14_Test.zip/file

It contains some new pathing logic, and a debug dialog that pops up if the 0x14 error is hit.
Perhaps we can learn more about the permissions issues, with this dialog, if that is actually the cause of these problems.

Thank you so much for testing!

[Xanashi]

Once again, thank you for testing funky-d!

I've finally had the time to look a bit deeper into this, and now that I've looked at the code again, I've realized I may have been a bit of a fool and been looking in the wrong place all along.
I believe you were actually completely correct in your initial assumption, and that this is related to account impersonation.

Both IcarosConfig and the Icaros Cache impersonates the current user, when saving and retrieving Icaros settings from the Windows Registry. This is probably were things go awry and one or both processes fail to impersonate the current AD/Domain user correctly.

I'm currently thinking of ways to test this, but in the meantime, could you try the following fix for the "Illegal characters in path" error:

https://www.mediafire.com/file/igujworq96vdcoj/IcarosConfigFix.zip/file

IcarosConfig now uses .NET 4.6, but if you're on Windows 10+, no additional download should be required.

Otherwise installing .NET 4.6 is required:
https://download.microsoft.com/download/...OS-ENU.exe

[funky-d]

Hi Xanashi,

Confirming that the debug page now works correctly with your fix. Glad you have an idea what may be going on with the 0x14 error! It's possible this error may also happen when logging in with a Microsoft account. If I have some spare time this weekend I will spin up a VM and try logging in with a throwaway MS acct to see if the same error occurs.

Thanks again for the help, let me know if there is anything else I can do to test.

[funky-d]

Just a quick update, unfortunately (or fortunately in this case I guess), a Microsoft account does not exhibit the same issue as a domain joined account.

The only way I can think of testing this further is by setting up a virtual Windows AD environment. Are you using Hyper-V to test by chance? If so, I could possibly set up a quick test environment and send you an export of a domain joined Win11 VM. Unless the export/import process changes something, the VM should retain it's cached credentials and let you log in even if the domain controller is not present. Just let me know!

[Xanashi]

Hi funky-d,

Thank you so much again for testing, and I'm sorry I'm so slow to reply.
I've been trying on a MS enabled account as well, and didn't see any issues, like you.

I would love to try to reproduce the bug with your virtual Windows AD environment. That would be an incredible help.
And would save me a lot of time setting up an AD environment myself.

If you want to send the environment in a more private fashion, just mail me directly at xanashi[at]gmail[dot]com.

[funky-d]

Hi Xanashi,

Thanks for the response, I just emailed you the test VM. Hopefully this helps!

[Xanashi]

funky-d and I finally got this one fixed together.
The fix is now available in 3.3.1 Beta 1!

Thank you so so much for your incredible help in troubleshooting this issue, funky-d! ❤️