Kernel32.GetCurrentPackageFullName (15700)

[kippies]

FIlebot has worked great for me since I bought the windows store version, great little tool.

As of 3 days ago it has died.

First symptom- clicking on the tile gave the generic "windows cannot find the path or file specified, blah blah"
Solution- searched for filebot launcher ran that instead- cushty

Next sympton- filebot compaining about missing desktop bridge. Unistalled, reinstalled, fixed.

Next sympton has me stuck- hitting rename results in "illegal state exception, kernel32GetCurrentPackageFullName (15700)"

Ran from command line and was presented with this output

Code: Select all

[0x7FFFC70F37B0] ANOMALY: meaningless REX prefix used
[0x7FFFC70F3F20] ANOMALY: meaningless REX prefix used
IllegalStateException: Kernel32.GetCurrentPackageFullName (15700)
java.lang.IllegalStateException: java.lang.IllegalStateException: Kernel32.GetCurrentPackageFullName (15700)
        at net.filebot.LicenseModel$1.check(LicenseModel.java:20)
        at net.filebot.ui.rename.RenameAction.lambda$actionPerformed$1(RenameAction.java:89)
        at net.filebot.util.ui.SwingUI.withWaitCursor(SwingUI.java:333)
        at net.filebot.ui.rename.RenameAction.actionPerformed(RenameAction.java:74)
Caused by: java.lang.IllegalStateException: Kernel32.GetCurrentPackageFullName (15700)
        at net.filebot.platform.windows.WinAppUtilities.getPackageName(WinAppUtilities.java:52)
        at net.filebot.LicenseModel$1.lambda$$0(LicenseModel.java:11)
        at net.filebot.MemoizedResource.get(Resource.java:36)
        at net.filebot.LicenseModel$1.check(LicenseModel.java:16)

Any idea what going on?

[rednoah]

15700 means that the process does not have a UWP context, which is likely caused by not running the app / command via the appropriate interfaces, and instead breaking the WindowsApps folder permissions and accessing application files directly.


1.
Please post the command you're using and the value of the %PATH% environment variable.


2.
The executables for commands installed via the Store are here:

Code: Select all

%USERPROFILE%\AppData\Local\Microsoft\WindowsApps

This path is in the %PATH% by default.

The WindowsApps folder has special permissions because you're never supposed to access it, even if you're a power user.

When you start an app via the standard interfaces (e.g. tile or command) then it'll start a UWP context and run the executable within that. But if you pry open the WindowsApps folder and double-click an executable, you'll be running it in the classic Win32 context, without UWP context / file system indirection / registry indirection / etc. It might work for Desktop Bridge apps that don't use UWP, but more accidentally than by design.

[kippies]

command from CMD is just vanilla "filebot" - no arguments.

Yup your right about how I've broken it- acessed the apps folder when the tile would not work and ran from the launcher.

Path is-


Output of sysnfo from CMD

"access is denied"

[jonnwhite]

I'm having this issue too.
How can i resolve?

Worked perfectly till i updated tonight. I have put all the permissions back to what they where.

many thanks
Jon

[rednoah]

Same answer applies:

15700 means that the process does not have a UWP context, which is likely caused by not running the app / command via the appropriate interfaces, and instead breaking the WindowsApps folder permissions and accessing application files directly.

The executables for commands installed via the Store are here:

Code: Select all

%USERPROFILE%\AppData\Local\Microsoft\WindowsApps

This path is in the %PATH% by default.

The WindowsApps folder has special permissions because you're never supposed to access it, even if you're a power user.

When you start an app via the standard interfaces (e.g. tile or command) then it'll start a UWP context and run the executable within that. But if you pry open the WindowsApps folder and double-click an executable, you'll be running it in the classic Win32 context, without UWP context / file system indirection / registry indirection / etc. It might work for Desktop Bridge apps that don't use UWP, but more accidentally than by design.

It's basically a Store issue, and the newer versions actually require you to run things the Store way. Doing things the wrong way may have accidentally worked previously, but it wasn't actually supposed to.

There's two options. The first option is to just factory reset your machine, and then the Microsoft Store will just work. Since that's inconvenient, fixing the Store without doing a clean reset is something you could try, but that's just Google and luck and success is not guaranteed.

As a last resort, if you send me your Microsoft Store purchase confirmation + name + email, then I can just issue you a test license for the non-Store edition of FileBot, which neatly avoids the Store altogether.

[kippies]

As obviously Id messed up permissions I just did a reinstall. Everythings cushty after that. Thanks for the support RedNoah, for a small DEVTeam, support is excellent.

[jonnwhite]

HI Both,

thank you very much for your help.

I tried a windows store repair on the off change.
the troubleshooter didnt work however re registering the store and then removing and reinstall filebot fixed the issue, no need for reinstall

thanks
jon