App Won't Launch on Windows 10

Yes, I’ll ask them, thanks!

I assume it depends on their setup if they have some internal policy that is preventing elevation or at least the uac to show then the elevation will fail. According to the info on that link this should have the best opportunity to show the uac for elevation.

That being said, is your install script [Run] section actually set to run anything elevated? It might be a misconfig in that and the problem might be worked around if that elevation request is stopped.

All guess work as I’ve not done an inno script in a long time.

I think the installer is working fine, everything gets installed that should be. It’s just that when you try to run the actual app (whether once or a dozen times), it either fails to launch or comes to half-life for a moment and then closes, sometimes with the permissions message, but not usually.

In Build Settings, is your app built with user level security privileges or administrator level?

I haven’t looked at that setting in many years, it’s set to User. I have a lot of organizations that are customers, I can’t imagine they’d want all of their users to have admin privileges, but I’ll switch it to Highest Available, hopefully that will work for everybody. Thanks for the reminder!

User is fine if you aren’t doing anything that needs elevation, I’m just trying to figure out what needs the elevation that is failing.

What does the [Run] section of your install script look like?

It’s not the installer that’s failing, it’s the actual app.

Has the user even been able to get the registration screen to show or does it break before that?

Have you check the eventlog for any additional information?

It breaks before the splash screen, they don’t even get as far as the registration screen.

I’m not sure what/where the eventlog would be.

Something that came to mind just now is that I use Aaron Ballman’s “Spiffy Mutex” IPCSocket code to determine whether or not another instance of the app is already running on Windows. That’s really early in the launch process and it uses SpecialFolder.ApplicationData.child(“com.mckernon.lightwright6.socket”).

Hmmm…

This is interesting, I commented out Aaron Ballman’s “Spiffy Mutex” code and Lightwright launched successfully on my user’s problematic computer.

I can’t get debug log information about this because Lightwright closes before the logging starts, but it’s a beginning. It’s just odd that code that Aaron’s code that’s been working for probably 10-15 years suddenly ran into problems and as far as I can tell there haven’t been any recent Xojo changes to Mutex or IPCSockets.

Weird…

Do you have a link to the code?

Not the original, a chunk of it is from Windows Functionality Suite 2.5.1, but the working part that I use is all from PDFs of Aaron Ballman’s “Ramblings” dated 2005 - “How to use a Mutex” parts 1 and 2. If you send me your email address privately, I’ll be happy to email the stuff to you.

One note: The user still hasn’t said “yes”, Lightwright runs fine if I hold down the Ctrl key while launching, to prevent it from doing Mutex and IPC calls.

And I just made a really weird discovery. The debug log’s last entry in every case is at “Getting Default Printer Setup”. Here’s the code:

==========================================
DebugLogThis(“Getting Default Printer Setup”)

gPrinterSetup=GetDefaultPrinterSetup(False)

'GetDefaultPrinterSetup does Dim ps as New PrinterSetup, then sets ps.MaxHorizontalResolution=300 and 'ps.MaxVerticalResolution=300, then gets values ps.PageLeft, .PageTop

If gPrinterSetup<>Nil Then

If Not gPrinterSetup.IsValidPrinterSetup Then
gPrinterSetup=Nil
gPrinterSetup=New PrinterSetup
End If

End If

InitUDP 'The InitUDP method’s first statement is: DebugLogThis(“Init UDP”), which is not in the log

==========================================

So maybe the problem is a bad printer driver?

Thoughts?

Do they have one installed?

I asked the customer, no reply yet…

Well the mutex issue isn’t the problem if it gets past it :slight_smile:

It might be that the user hasn’t finished setting up their printer which is requiring elevation.

If you want to stop the elevation of a new process spawned from your app, you can set this before hand:

System.EnvironmentVariable("__compat_layer") = "RunAsInvoker"

then to set it back again before you run your elevated registry editor exe use:

System.EnvironmentVariable("__compat_layer") = ""

it might be worth setting that just before the call to GetDefaultPrinterSetup to see if it makes any difference. This will mean that the CreateProcess shouldn’t fail due to an elevation issue, but it might fail due to itself not being able to elevate. On the other hand, if it needs elevation and it isn’t getting it, then it might need “RunAsAdmin” which should pop up the UAC no matter what.

But things will be clearer when they back to you on what’s being tested.

1 Like

I heard back from one of the users who had this problem, her report now is that Lightwright is launching, though she hasn’t done anything new to her computer. Instead, Lightwright quits suddenly whenever she tries to print. That makes sense if the problem is with GetDefaultPinterSetup (or whatever Windows sends it).

I’ll put together a build for her with your _compat_layer code and see what happens.

Hopefully I’ll also hear back from her and also one of the other users with this problem.

The story continues…:slight_smile:

A bit of a guess … I’ve seen some software that is unhappy if there is no printer set as the default printer. Recently Windows encourages users to not specify a default printer and let Windows decide which printer to use. (This can work well for portable computers that used in different locations, but is useless or confusing for most desktop computers.)

I finally heard back from one of the users. The problem was caused by their printer being a remote one on their network. When they switched to a local printer, everything was fine. Which raises the question for Xojo of why and how could this problem be trapped or the user notified before the app quits unexpectedly?

3 Likes

You have three cases:
a. a default printer have not been set in the running computer,
b. the default printer is OFF line (or shut down),
c. a default printer have been set and the printer is ON.

You probably found a declare here (for MacOS):

The code have to be fired at application Open time (App.Open).

Probably the same for other platforms.

I forgot what needs to be done, but a valid object have to be created (last time I heard about this question was in… 1989 !)