Can we have multiple fixes at the same time

Copper Contributor

Dear Experts,

 

Assume i have a msix package that needs multiple fixes like

1)FRF

2)Registry

3)Trace

 

Can we have the three fixes together ?

 

i have been trying this but was not lucky enough..

 

Below is the config.json i was trying

 

{
    "applications": [
        {
            "id""MyPackagex64",
            "executable""VFS/ProgramFilesX64/ConEmu/MyPackage64.exe",
            "workingDirectory""VFS/ProgramFilesX64/MyPackage"
        },
        {
            "id""ConEmuAAx64A1",
            "executable""VFS/ProgramFilesX64/ConEmu/MyPackage64.exe",
            "workingDirectory""VFS/ProgramFilesX64/MyPackage"
        }
    ],
    "processes": [
        {
            "executable""MyPackage64",
            "fixups": [
                {
                    "dll""FileRedirectionFixup64.dll",
                    "config": {
                        "redirectedPaths": {
                            "knownFolders": [
                                {
                                    "id""ProgramFilesX64",
                                    "relativePaths": [
                                        {
                                            "base""MyPackage/",
                                            "patterns": [
                                                ".*"
                                            ]
                                        }
                                    ]
                                }
                            ]
                        }
                    }
                },
                {
                    "dll""TraceFixup64.dll",
                        "config": {
                            "traceMethod""outputDebugString",
                            "traceLevels": {
                                "default""always"
                            },
                            "breakOn": {
                                "filesystem""unexpectedFailures"
                            }
                        }
                    }
            ]
        },
        {
            "executable""MyPackage64",
            "fixups": [
                {
                    "dll""FileRedirectionFixup64.dll",
                    "config": {
                        "redirectedPaths": {
                            "knownFolders": [
                                {
                                    "id""ProgramFilesX64",
                                    "relativePaths": [
                                        {
                                            "base""MyPackage/",
                                            "patterns": [
                                                ".*"
                                            ]
                                        }
                                    ]
                                }
                            ]
                        }
                    }
                },
                {
                    "dll""TraceFixup64.dll",
                        "config": {
                            "traceMethod""outputDebugString",
                            "traceLevels": {
                                "default""always"
                            },
                            "breakOn": {
                                "filesystem""unexpectedFailures"
                            }
                        }
                    }
            ]
        }
    ]
}
28 Replies

Hey @Sleeping_Developer ,

 

I took a look at your supplied Json.config file.  First off there are no json syntax errors, that is good.

 

Besides the syntax I see you declared fixups for the same process, was that expected?

 

The syntax for the config sections look good as well.  Tell me, for the FRF work fine on it's own?

 

Also, to answer your question, it is okay to declare multiple fixups for the same process.

@Darren_Hoehna Thank you for the reply,

1)File redirection fix up didn't work for me

2)Yeah, i am trying to applying both fix up for the same process, is there any problem if i do so ?

 

Please help me if there is another way to apply fix ups.

Hey@Sleeping_Developer ,

 

Your file redirection is not working?  Well, we need to make sure FRF works before moving to adding a second fixup.

 

First, I want to make sure you have all the dll's and exe's in your app folder.  You will need

1. PSFLauncher64.exe

2. FileRedirection64.dll

3. PsfRunDll64.exe

Those three dll's are needed to have PSF run correctly.

 

Next, the configuration.  It looks like you want all file operations under ProgramFilesX64\MyPackage\* to be redirected.  PSF should redirect all file operations to that location.  If you have the three binaries mentioned in step 1 but PSF does not redirect the files I'll need to dig deeper.

 

You are absolutely correct about two or more fixups.  But, you don't need to declare two process nodes.  You can put both fixups under the same process.  You can remove the second "MyPackage64" executable node.

 

@Sleeping_Developer In general, multiple fixups should work, but I would not want to attempt two fixups that attempt to intercept the same Windows API functions. 

So for example, the FRF and DynamicLibrary fixups address distinct sets of the API and work well together if needed. The Trace and FRF fixups intercept the same calls (Trace might be a considered a superset), and I would anticipate issues.

 

I use the trace fixup only to determine what might be required by seeing what the application is attempting to do and how the runtime without the FRF responds.  When using the FRF without trace but wanting tracability, you should probably use the debug build version of the FRF.  This will output considerable detail to the debug port, which you can view using something like the Microsoft Sysinternals tool DbgView.

 

If you are creating your MSIX package by repackaging using the Microsoft MSIX Packaging Tool, you can use PsfTooling (free app in the Microsoft Store) to inject the debug version of the PSF into your package.  The tool has two shortcuts (PsfTooling and PsfToolingD), one for the release build and the second for the debug build of the PSF.

 

If building your package as a developer, just include the debug build of the FRF the same way you are doing now, just without the trace.

@Tim Mangan Thank you so much for the information!

@Darren_Hoehna Thank you for the help!it worked well! Apologies for late reply!

Dear @Tim Mangan ,

 

I have another question how build msix using debug version of FRF? is there separate library available or configuration?

 

Thank you,

Vikas

@tester2420 

 

Assuming you mean build from source, you just ask for the Debug configuration before you buld.

 

If you were thinking about the NuGet package, I believe they only offer the release build, so you'd be looking at downloading the source and building your own version.

 

Instructions for using the prebuilt PSF debug in PsfTooling was in a previous response.  PsfTooling has two shortcuts, one with the release build and another with the debug.

 

 

 

@Tim Mangan ,

 

Thank you so much for the response, i will build the setup locally.

I am facing one strange issue with Tracefixup and thats where i am trying to explore FRF debug build,

 

Latest builds of PSF is crashing for TRACE module saying PSFLauncher64.exe have encountered some problem and if i go back to older version of PSF framework, it is not able to match ID's from Manifest file of config.json :(.

Please help me if you have seen this kind of error before.

 

Kind Regards,

Vikas

@tester2420 There were some crash situations occurring in PsfLauncher that I fixed in a pull request last week that is in the Develop branch.  You might want to download that branch and try it.

@Tim Mangan 

 

Thank you so much for the response!i am continuously seeing this error also 

 

Package support framework

Error: Could not find matching appid in config.json and appx manifest:

Element not found

(1168)

 

Though the error is very descriptive an informative but when i look back at my json and appx manifest, i see they have matching element.it seems something else is missing out.

 

 

Thank you,

Vikas

 

@tester2420 When the PSF is not in use, you can do whatever you want in the manifest for the AppID field, but not so when the PSF is in use.

 

The PsfLauncher uses an algorithm that takes the name of its process and turns it into an AppID that matches how the MSIX Packaging tool would have created it.  It then looks for an application entry in the config.json file that matches that AppId.  The algorithm is still undocumented to the best of my knowledge, but @James Pike provided an unofficial summary of it in this reply on the community portal.

 

So if your PsfLauncher64.exe is the process, the config.json entry for the application should have an appid of "PSFLAUNCHERSIXFOUR".  Totally obvious, right? 

@Tim Mangan 

 

Thanks once again for the reply, I was trying to update the config file to see the success but PSFLauncher64.exe is haunting me, its continue to crash, so i took the latest branch and was trying to compile 

I see initialize has 3 arguments

 

void Initialize(const psf::json_object* appConfig, const std::filesystem::path& currentDirectory, const std::filesystem::path& packageRootDirectory)

 

but only 2 params are passed.

powershellScriptRunner.Initialize(appConfig, currentDirectory); 

 

the branch I cloned is :

https://github.com/microsoft/MSIX-PackageSupportFramework/tree/develop

 

and its a compilation error.

Anything I am missing?

 

Thank you,

Vikas

Locally fixed it
powershellScriptRunner.Initialize(appConfig, currentDirectory, packageRoot);

@tester2420 Good. That's what I was going to suggest.  I discovered earlier this week that some of the changes in the PR didn't get integrated causing the issue you've seen. There will be a new PR shortly to fix that in the sources.  I don't think any other issues from the missing changes should affect you.

Dear @Tim Mangan 

 

I have another doubt, let say there is more than one entry point and i want to apply fix, Id will be

"id": "PSFLAUNCHERSIXFOUR" for each entry point and this will lead to schema validation error.

 

How to handle this situation.

 

Kind regards,

Vikas

@Sleeping_Developer The solution to the multiple entrypoints to the same exe issue I solve by making copies of the PsfLauncherxx.exe file.  Each entrypoint gets a unique name, and thus unique munged ID.

 

In PsfTooling they get copied as Psflauncher1.exe, PsfLauncher2.exe, and so on for the shortcuts; PsfLauncherFTA1.exe and so on for the FTAs (when necessary).  You could keep the bitness in those names, but the munched ID is capped at 16 characters so watch out.

 

Thank you so much @TIMOTHY MANGAN , i have tried this and its working, Great!

now i am wondering if we can have two fixes for the same entry points(exe).

 

@TIMOTHY MANGAN 

 

Dear Tim,

 

I am having another encoding problem with notepad++

 

my config.json looks like this

"applications": [
{
"id": "PSFLAUNCHERSIXFOUR",
"executable": "VFS/ProgramFilesX86/Notepad++/notepad++.exe",
"workingDirectory": "VFS/ProgramFilesX86/Notepad++"
}
],
"processes": [
{
"executable": "notepad++",

 

and once i build the msix and launch it is giving regex error around encoding(i believe) regex_error

 
 

---------------------------
Package Support Framework
---------------------------
regex_error(error_badrepeat): One of *?+{ was not preceded by a valid regular expression.
---------------------------
OK
---------------------------

 

Please let me know if there is any solution for this i have tried escaping and encoding + by %20.

 

Kind Regards,

Vikas