Cameyo

Tsaukpaetra · Member

Registry virtualization not working

Tsaukpaetra · Member

It seems that, sometimes it actually is. Kinda.
Unfortunately, since the app is a console application, I can't launch it from Cameyo normally, so I've been fiddling with the command line options field for the packager, and I find that on occasion it starts up just slow enough for Cameyo to inject its stuff and it actually hits the virtualized registry properly. Of course, then it promptly fails to load the referenced file (for reasons), but it's almost a start.

mule · Guru

Please run your package with -infolog parameter and upload the text file that it produces, e.g. LocalDB_3.cameyo.exe -infolog

Tsaukpaetra · Member

This forum does not allow uploading txt files, so I made it as a pastebin.

https://pastebin.com/uppHj7iM

mule · Guru

Does the same thing happen when Virtualization is Disk mode?

Tsaukpaetra · Member

Yes, just a little bit faster after it does the initial extract. I started with that first, since it's the default, but thought that maybe it was starting up too fast for the hook to get attached. The program itself usually completes almost immediately.

mule · Guru

Did you enable Allow system services to be registered on target machine under the Advanced tab in Package Editor? If not, run package with -Remove parameter before running with system services enabled.

Tsaukpaetra · Member

Indeed I have tried this, but it seems not to help. The services (apparently) run while the app is launched, but are not really part of the problem. The main issue seems to be that Windows has loaded and started the tiny program so fast that the hooks that intercept the registry and filesystem calls haven't been applied before the program has accessed them already and failed.

mule · Guru

Please provide your package for us to take a look. Include any files and instructions necessary for us to reproduce. You can PM me the download link if you like. WeTransfer is a good option if you don't want to use your Google Drive.

Tsaukpaetra · Member

https://drive.google.com/open?id=1mMYlIKekdswdsI5BSH0XnGU1WnvqK4V3

Beware, Windows Defender thinks it's a Win32/Fuery.A!cl trojan for some reason.

-- Edited by Tsaukpaetra on Thursday 5th of April 2018 01:23:17 PM

mule · Guru

Your Process Monitor log does not show how you ran SqlLocalDB.exe create Test.

Was the log captured by running the package you uploaded and selecting Create [create test], or was SqlLocalDB.exe create Test run a different way?

I installed SqlLocalDB 2012, SqlLocalDB 2014, and SqlLocalDB 2016 natively. When I run your package, the only registry key seen in \Installed Versions is 14.0.

Tsaukpaetra · Member

For the first question, the SqlLocalDB.exe was ran under the Command prompt console because running the menu option made the console window fly by so fast I didn't even know if it was running or not. Essentially the command is identical to the description text.

I agree if you use Regedit from within the package it shows only version 14.0, because by the time regedit actually requests the key Cameyo hooks are installed and working. This appears to not be the case when running the sqllocaldb.exe from within the package.

Are you saying that in your procmon capture when running my package, the sqllocaldb.exe executable is indeed only seeing version 14.0? Because when I try it it's looping through the others like it would if it weren't packaged.

mule · Guru

Was the Command Prompt from the package, i.e. was it a virtualized Command Prompt, or was it unvirtualized, directly from the host system?

If you are running an unvirtualized %AppData%\VOS\LocalDB\PROG\%Program Files%\Microsoft SQL Server\140\Tools\Binn\SqlLocalDB.exe" create Test, it would make sense that it accesses the host system.

I ran Create [create test] from your module and the procmon capture saw only 14.0 in \Installed Versions. I also ran a virtualized Command Prompt from your package and then "C:\Program Files\Microsoft SQL Server\140\Tools\Binn\SqlLocalDB.exe" create test with the same result.

Tsaukpaetra · Member

It was command prompt launched from the package, though I may have broken that in the version I linked.

Wait, you ran it on a clean machine? Or the one where you installed every other version?

And what OS? I'm on Windows 10 1709 at home.

I'm baffled that you were able to get it working by all of my lab machines (and my home machines) seemingly cannot....

If you ran the Start option, does it run the sqlserver executable?

mule · Guru

I started with two clean VMs, one Win7 SP1 and one Win10 1709. I installed SqlLocalDB 2012, SqlLocalDB 2014, and SqlLocalDB 2016 natively, so that your package would be tested for seeing other keys on the host in Installed Versions, e.g. 11.0, 12.0, and 13.0. Procmon, however, indicated that your package saw only 14.0.

When I run SqlLocalDB.exe" create test, whether by selecting it from the first Cameyo menu item or by virtualized Command Prompt, I receive the error saying SqlUserInstance.dll not found.

Two questions:

Does your package successfully create test for you?
Would you provide a Process Monitor Log that shows these and any other relevant processes during the capture of running your package:
1. LocalDB_3.cameyo.exe
2. %AppData%\VOS\LocalDB\PROG\%Program Files%\Microsoft SQL Server\140\Tools\Binn\SqlLocalDB.exe" create test
3. rundll32.exe
4. cmd.exe

Tsaukpaetra · Member

No, this package fails entirely in all cases, unless the version it's expecting is actually locally installed (and it ends up using the non-packaged data, completely obviating the point).

I've found that severely limiting the running PC's resources lets me get to the point where it actually sees the right registry entries, but even when it does, it then moves on to try loading a DLL from the wrong architecture (based on the error code).

Link to part 2A of capture request.

Link to part 2B (running direct outside the package)

Link to capture that included rundll32.

It seems to be trying to load the 32-bit version of SqlUserInstance.dll when it asked for the 64-bit version (according to the path).

What should end up happening at the end of the Create operation is a folder in %LocalAppdata%\Microsoft\Microsoft SQL Server Local DB\Instances\Test with a bunch of files.

mule · Guru

Ah, it fails for you, too? Tsk, tsk. Yes, unfortunately Cameyo does not support virtualizing your software. I thought that maybe you had found a way to get closer to success, but alas. With Cameyo Online instead of Packager, you would install LocalDB natively on a Cameyo Server and have the ability to use the app through a browser. Depending on your uses, it might be a solution.

Tsaukpaetra · Member

I guess I don't understand your sarcasm.

My issue is that under normal circumstances, the application isn't getting hooked fast enough for Cameyo to provide the virtual registry and filesystem, and when it does, it's translating the program files directory wrong and giving the wrong DLL file. If it did what it said on the tin, I wouldn't be having any issues as far as I know.

The intent here is to *not* have to install the app on the target machine (technically, a little further, to be able to run it on a non-privileged account that *can't* install apps on the target machine), which may or may not have Internet access.

Bottom line is, the packager is failing and the "best" solution I've been given is "Well, run it on the Cloud!".

Tsaukpaetra · Member

Is there a special flag or something that will stop it translating "%Program Files%" into "%Program files (x86)%"? That would be my next goal, since this is indeed a 64-bit program and this "help" is the current breakage (after the registry hook issue).

Tsaukpaetra · Member

I guess I can just move the folder into one that's not expansion-replaced. Hmm...