Kernel32.GetCurrentPackageFullName (15700)

Support for Windows 10 users and the Microsoft Store package
Post Reply
kippies
Posts: 3
Joined: 17 Aug 2018, 00:00

Kernel32.GetCurrentPackageFullName (15700)

Post by kippies » 17 Aug 2018, 00:17

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?

User avatar
rednoah
The Source
Posts: 16615
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: ohhh windoze...

Post by rednoah » 17 Aug 2018, 04:37

:idea: 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.

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

:idea: 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. :lol:
:idea: Please read the FAQ and How to Request Help.

kippies
Posts: 3
Joined: 17 Aug 2018, 00:00

Re: Kernel32.GetCurrentPackageFullName (15700)

Post by kippies » 17 Aug 2018, 15:40

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-
Image

Output of sysnfo from CMD

"access is denied"

jonnwhite
Posts: 2
Joined: 17 Aug 2018, 19:55

Re: Kernel32.GetCurrentPackageFullName (15700)

Post by jonnwhite » 17 Aug 2018, 19:57

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

User avatar
rednoah
The Source
Posts: 16615
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Kernel32.GetCurrentPackageFullName (15700)

Post by rednoah » 17 Aug 2018, 20:13

Same answer applies:
rednoah wrote:
17 Aug 2018, 04:37
:idea: 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.
rednoah wrote:
17 Aug 2018, 04:37
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.

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

:idea: 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. :lol:
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.
:idea: Please read the FAQ and How to Request Help.

kippies
Posts: 3
Joined: 17 Aug 2018, 00:00

Re: Kernel32.GetCurrentPackageFullName (15700)

Post by kippies » 19 Aug 2018, 02:43

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
Posts: 2
Joined: 17 Aug 2018, 19:55

Re: Kernel32.GetCurrentPackageFullName (15700)

Post by jonnwhite » 19 Aug 2018, 12:58

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

Post Reply