#804 closed defect (invalid)

Could not load qgis_app.dll - QGIS LTR 3.28.11 OSGeo4W Installer

Reported by: ascottwwf Owned by: osgeo4w-dev@…
Priority: normal Component: Installer
Version: 1.0 Keywords: QGIS LTR OSGeo4W scripted installer
Cc: ascottwwf

Description (last modified by jef)

I tried raising this issue with QGIS but I was pointed in your direction.

What is the bug or the crash?

After either a fresh install (or an upgrade install) of QGIS LTR using the OSGeo4W installer, the QGIS application will not start as it errors with:

QGIS Install Error

Steps to reproduce the issue

We deploy QGIS LTR to a small number of users using Intune as our Application deployment method, this is deployed using a PowerShell script (originally sourced from: https://gist.github.com/Guts/6303dc5eb941eb24be3e27609cd46985), my slightly modified script is as follows:

"Begin: $ENV:PROCESSOR_ARCHITECTURE" >> "C:\Windows\Temp\Test.txt"
If ($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
     Try {
         &"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
     }
     Catch {
         Throw "Failed to start $PSCOMMANDPATH"
     }
     Exit
}

"End: $ENV:PROCESSOR_ARCHITECTURE" >> "C:\Windows\Temp\Test.txt"
#Requires -RunAsAdministrator

<#
=========================================================================================
Install-OSGeo4W_QGIS-LTR.ps1
-----------------------------
.Synopsis
   Download the OSGeo4W installer then download and install QGIS LTR (through the 'full' meta-package).
.DESCRIPTION
   This script will:
      1. change the current directory to the user downloads folder
      2. download the OSGeo4W installer
      3. launch it passing command-line parameters to INSTALL QGIS LTR
    Documentation reference: https://trac.osgeo.org/osgeo4w/wiki/CommandLine
#>

<#
=========================================================================================
Adrian Scott
7th December 2022

Original file sourced from: https://gist.github.com/Guts/6303dc5eb941eb24be3e27609cd46985

=========================================================================================
#>

Write-Host "=== Start installing / upgrading QGIS LTR..." -ForegroundColor Green

# Save current working directory
$starter_path = Get-Location

# Move into the user download directory
Set-Location -Path "$($env:USERPROFILE)\Downloads"

# Set saved name of File to be downloaded
$OutFile = "osgeo4w-setup.exe"

# Download installer
Write-Host " = Start downloading the OSGeo4W installer..." -ForegroundColor Yellow
Invoke-WebRequest -Uri "https://download.osgeo.org/osgeo4w/v2/osgeo4w-setup.exe" -OutFile $OutFile

# Download and install (same command to upgrade with clean up)
Write-Host " = Start installing / upgrading QGIS LTR..." -ForegroundColor Yellow
& .\$($OutFile) `
    --quiet-mode `
    --advanced `
    --arch x86_64 `
    --autoaccept `
    --delete-orphans `
    --local-package-dir "$($env:APPDATA)\OSGeo4W_v2-Packages" `
    --menu-name "QGIS LTR" `
    --no-desktop `
    --packages qgis-ltr-full `
    --root "$($env:ProgramFiles)\OSGeo4W_v2" `
    --site "https://www.norbit.de/osgeo4w/v2" `
    --site "https://download.osgeo.org/osgeo4w/v2" `
    --site "https://ftp.osuosl.org/pub/osgeo/download/osgeo4w/v2" `
    --upgrade-also `
 | out-null

# Return to the initial directory
Set-Location -Path $starter_path
Write-Host "==== Work is done!" -ForegroundColor Green

So, up until the release of QGIS LTR version 3.28.9 (or 3.28.8), this script had worked fine, but since then we have been seeing this issue

This issue occurs on both fresh installs and upgrade installs (this is similar to the earlier reported QGIS issue #49148). We use the OSGeo4W installer to install (and/or upgrade) QGIS LTR

From my basic understanding it appears that during the install, the path environment does not get updated (as it had previously), so when running the QGIS application the qgis_app.dll can not be found, hence the error message. I also note that on a new and upgraded install that the qgis-ltr-bin.env file does not exist so it is not possible to Check this file for correct environment paths. I have re-visited the command line syntax for the OSGeo4W installer, to double check there is no changes to the syntax (or mistakes in my command), but all seems as it always has. FYI: All our devices run Windows 10 Enterprise (x64) version 22H2 with latest September (or August) 2023 Windows updates installed i.e. Build 10.0.19045.3348

I suspect the installer is failing to complete at some point and not running the procedure that amends the environment path

Attachments (4)

QGIS Install Error.png (12.8 KB ) - added by ascottwwf 14 months ago.
QGIS Install Error
setup.log.full (154.5 KB ) - added by ascottwwf 14 months ago.
setup.log.full
setup.log (161.3 KB ) - added by ascottwwf 14 months ago.
setup.log
setup.2.log (86.3 KB ) - added by ascottwwf 14 months ago.
setup.log (From Sandbox)

Download all attachments as: .zip

Change History (20)

by ascottwwf, 14 months ago

Attachment: QGIS Install Error.png added

QGIS Install Error

comment:1 by ascottwwf, 14 months ago

Description: modified (diff)

comment:2 by ascottwwf, 14 months ago

Description: modified (diff)

comment:3 by ascottwwf, 14 months ago

Description: modified (diff)

comment:4 by jef, 14 months ago

Following works fine in a windows 11 sandbox for me:

pushd %USERPROFILE%\Downloads
curl -LO https://download.osgeo.org/osgeo4w/v2/osgeo4w-setup.exe & osgeo4w-setup ^
  --quiet-mode ^
  --advanced ^
  --arch x86_64 ^
  --autoaccept ^
  --delete-orphans ^
  --local-package-dir "%APPDATA%\OSGeo4W_v2-Packages" ^
  --menu-name "QGIS LTR" ^
  --no-desktop ^
  --packages qgis-ltr-full ^
  --root "%ProgramFiles%\OSGeo4W_v2" ^
  --site "https://www.norbit.de/osgeo4w/v2" ^
  --site "https://download.osgeo.org/osgeo4w/v2" ^
  --site "https://ftp.osuosl.org/pub/osgeo/download/osgeo4w/v2" ^
  --upgrade-also
popd

Did you check setup.log or setup.log.full in %ProgramFiles%\OSGeo4W_v2\var\log? If qgis-ltr-bin.env is missing, then %OSGEO4W_ROOT%\etc\postinstall\qgis-ltr.bat probably didn't run correctly (should be qgis-ltr.bat.done afterwards). Without the proper .env file the exe will not run.

You could find more details using the hints in QGIS #26891 (also mentioned in QGIS #49148)?

Last edited 14 months ago by jef (previous) (diff)

comment:5 by jef, 14 months ago

Description: modified (diff)

by ascottwwf, 14 months ago

Attachment: setup.log.full added

setup.log.full

by ascottwwf, 14 months ago

Attachment: setup.log added

setup.log

comment:6 by ascottwwf, 14 months ago

I have attached both log files to this issue, these are from my machine that is being upgraded.
I will re-run the install on my Windows 10 sandbox (a fresh install) and get you the logs from there later.

Although I don't know exactly what I'm looking for, there is the following 'Fatal Python error' that occurs in the setup.log.full file "ModuleNotFoundError: No module named 'encodings'"

Here is the snippet (from lines 1707 to 1741 of the setup.log.full file) - I fully accept this may (or may not) be a reason for the issue:

2023/09/19 10:47:50 Running preremove script for  python3-pillow
2023/09/19 10:47:50 running: cmd.exe /c "C:\Program Files\OSGeo4W_v2\\etc\preremove\python3-pillow.bat"


C:\Program Files\OSGeo4W_v2>python3 -B "\Scripts\preremove-cached.py" python3-pillow 

Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'python3'
  isolated = 0
  environment = 1
  user site = 1
  import site = 1
  sys._base_executable = 'C:\\Program Files\\OSGeo4W_v2\\bin\\python3.exe'
  sys.base_prefix = ''
  sys.base_exec_prefix = ''
  sys.platlibdir = 'lib'
  sys.executable = 'C:\\Program Files\\OSGeo4W_v2\\bin\\python3.exe'
  sys.prefix = ''
  sys.exec_prefix = ''
  sys.path = [
    'C:\\Program Files\\OSGeo4W_v2\\bin\\python39.zip',
    '.\\DLLs',
    '.\\lib',
    'C:\\Program Files\\OSGeo4W_v2\\bin',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00003bb8 (most recent call first):
<no Python frame>
2023/09/19 10:47:50 abnormal exit: exit code=1
2023/09/19 10:47:50 Uninstalling python3-pillow

Reviewing your suggestion, it does look like the %OSGEO4W_ROOT%\etc\postinstall\qgis-ltr.bat probably ran correctly as there is a copy of qgis-ltr.bat.done in the postinstall folder, the modified date of the file is 15th Sept 2023 15:50 - I assume(?) this is the correct modified time I should expect to see for the file (I installed this on the 19th September so the modified time pre-dates the install date / time I would expect).
The .env file(s) do not exist.

Last edited 14 months ago by ascottwwf (previous) (diff)

comment:7 by jef, 14 months ago

qgis-ltr.bat --postinstall called from the postinstall should have created the .env. So I'd continue with QGIS #26891 and check if anything stands out in %TEMP%\qgis_app.log, when qgis-ltr.bat --postinstall is rerun.

by ascottwwf, 14 months ago

Attachment: setup.2.log added

setup.log (From Sandbox)

comment:8 by ascottwwf, 14 months ago

Sorry for the delay, I have not been able to get version 3.28.11 to successfully run after completing a fresh install in my Sandbox, I get the same error message as before.

As I was wondering if it was related to the install path having a space in it, as a test I modified my install script (Changed '--root' (destination path) from "C:\Program Files\OSGeo4W_v2" to "C:\ProgramData\OSGeo4W_v2"

My full (PowerShell) install script is now:

"Begin: $ENV:PROCESSOR_ARCHITECTURE" >> "C:\Windows\Temp\Test.txt"
If ($ENV:PROCESSOR_ARCHITEW6432 -eq "AMD64") {
     Try {
         &"$ENV:WINDIR\SysNative\WindowsPowershell\v1.0\PowerShell.exe" -File $PSCOMMANDPATH
     }
     Catch {
         Throw "Failed to start $PSCOMMANDPATH"
     }
     Exit
}

"End: $ENV:PROCESSOR_ARCHITECTURE" >> "C:\Windows\Temp\Test.txt"
#Requires -RunAsAdministrator

<#
=========================================================================================
Install-OSGeo4W_QGIS-LTR.ps1
-----------------------------
.Synopsis
   Download the OSGeo4W installer then download and install QGIS LTR (through the 'full' meta-package).
.DESCRIPTION
   This script will:
      1. change the current directory to the user downloads folder
      2. download the OSGeo4W installer
      3. launch it passing command-line parameters to INSTALL QGIS LTR
    Documentation reference: https://trac.osgeo.org/osgeo4w/wiki/CommandLine
#>

<#
=========================================================================================
Adrian Scott
7th December 2022

Original file sourced from: https://gist.github.com/Guts/6303dc5eb941eb24be3e27609cd46985

=========================================================================================
#>

Write-Host "=== Start installing / upgrading QGIS LTR..." -ForegroundColor Green

# Save current working directory
$starter_path = Get-Location

# Move into the user download directory
Set-Location -Path "$($env:USERPROFILE)\Downloads"

# Set saved name of File to be downloaded
$OutFile = "osgeo4w-setup.exe"

# Download installer
Write-Host " = Start downloading the OSGeo4W installer..." -ForegroundColor Yellow
Invoke-WebRequest -Uri "https://download.osgeo.org/osgeo4w/v2/osgeo4w-setup.exe" -OutFile $OutFile

# Download and install (same command to upgrade with clean up)
Write-Host " = Start installing / upgrading QGIS LTR..." -ForegroundColor Yellow
& .\$($OutFile) `
    --quiet-mode `
    --advanced `
    --arch x86_64 `
    --autoaccept `
    --delete-orphans `
    --local-package-dir "$($env:APPDATA)\OSGeo4W_v2-Packages" `
    --menu-name "QGIS LTR" `
    --no-desktop `
    --packages qgis-ltr-full `
    --root "$($env:ProgramData)\OSGeo4W_v2" `
    --site "https://www.norbit.de/osgeo4w/v2" `
    --site "https://download.osgeo.org/osgeo4w/v2" `
    --site "https://ftp.osuosl.org/pub/osgeo/download/osgeo4w/v2" `
    --upgrade-also `
 | out-null

# Return to the initial directory
Set-Location -Path $starter_path
Write-Host "==== Work is done!" -ForegroundColor Green

I therefore can only conclude this _must_ be an installation bug of some sort? I have attached the new setup.log file from the Sandbox for further investigation (I can not attach the setup.log.full as it is too big to attach to this case - it is 292Kb when it is zipped)

Last edited 14 months ago by ascottwwf (previous) (diff)

comment:9 by jef, 14 months ago

Have you tried the batch file that works for me? Probably not the culprit as it is the same AFAICT.

What about #7

comment:10 by ascottwwf, 14 months ago

Thanks Jef (and apologies for the delay in getting back to you) I have just updated the QGIS ticket (https://github.com/qgis/QGIS/issues/54678) although I've not seen any response from them recently....

It looks like your advice in comment 7 'may' be part of the solution. Not sure if this 'fix' is QGIS' responsibility or OSGeo's to resolve, anyhow I think we may be getting nearer to a conclusion. :-)

FYI: I'd rather not have to re-write our installation routine if it is only to fix a bug that had not affected us previously, so looking forward to an official fix in the install routine

Thanks, Adrian

comment:11 by jef, 14 months ago

Huh? Please check using the procedure from the comment what is the problem on your machines as this doesn't seem to be a general issue.

Last edited 14 months ago by jef (previous) (diff)

comment:12 by ascottwwf, 12 months ago

I have just retried this with the latest 3.28.12 LTR version (on a Windows 10 Sandbox) and unfortunately I am still getting the same issue.

But, I may have already discovered a fix... If after the install, I open a command prompt on the machine and then re-run:

%OSGEO4W_ROOT%\etc\postinstall\qgis-ltr.bat --postinstall

I get:

C:\ProgramData\OSGeo4W_v2>call "\bin\o4w_env.bat"
The system cannot find the path specified.

C:\ProgramData\OSGeo4W_v2>if not defined OSGEO4W_DESKTOP for /F "tokens=* USEBACKQ" %F IN (`getspecialfolder Desktop`) do set OSGEO4W_DESKTOP=%F
'getspecialfolder' is not recognized as an internal or external command,
operable program or batch file.

C:\ProgramData\OSGeo4W_v2>for /F "tokens=* USEBACKQ" %F IN (`getspecialfolder Documents`) do set DOCUMENTS=%F
'getspecialfolder' is not recognized as an internal or external command,
operable program or batch file.

C:\ProgramData\OSGeo4W_v2>set APPNAME=QGIS Desktop 3.28.12

C:\ProgramData\OSGeo4W_v2>for %i in ("") do set QGIS_WIN_APP_NAME=%~ni\QGIS Desktop 3.28.12

C:\ProgramData\OSGeo4W_v2>set QGIS_WIN_APP_NAME=\QGIS Desktop 3.28.12

It appears the command cannot correctly resolve the path, so if I change to the %OSGEO4W_ROOT% folder and run by calling the batch file, I get the same results:

call "\bin\qgis-ltr.bat" --postinstall
The system cannot find the path specified.

But, if I change to the %OSGEO4W_ROOT% folder and run:

call ".\bin\qgis-ltr.bat" --postinstall

It works... N.B. Pre-fixing the . ahead of the path allows the command to run.... and QGIS will then run / load.

The question now is why does this work on some machines but not others ? and what causes the failure? - Seems like some devices can not resolve the path as it is specified in the script.

Does this diagnosis help at all?

comment:13 by jef, 12 months ago

Are you running this from the OSGEO4W-Shell? Otherwise %OSGEO4W_ROOT% is not set.

in reply to:  13 comment:14 by ascottwwf, 12 months ago

Replying to jef:

Are you running this from the OSGEO4W-Shell? Otherwise %OSGEO4W_ROOT% is not set.

"OSGEO4W-Shell" - Sorry I'd not heard of that or how to run it, but I have now done some reading and understand, but realise this won't exist until the product is mainly installed

Therefore unless the installer uses the OSGEO4W-Shell during the setup - I am not running it this way, this is being run during the PowerShell script install - See: https://trac.osgeo.org/osgeo4w/ticket/804#comment:8 above, however I believe the qgis-ltr.bat gets executed towards the end of the installation - it's just it does not appear to run correctly on our Windows 10 machines (or our Windows 10 Sandboxes) - I notice your initial test was on a Windows 11 Sandbox (and you had used a slightly modified 'Not strictly a Powershell' version of my script).

I do have some concerns about the install - as good as it is, it does look heavily ported from Linux and in the logs there are quite a few forward slashes "/" in the paths to files which I am unsure if this is a logging issue or the actual command that is being run as you may know Windows has always used backslashes "\" to delineate between folders, so these commands may not work, I have also noticed some double backslashes "\\" in the logs too, so some paths written to the log have one or the other (not noticed any occurances of both combinations) e.g.

1) 2023/11/20 15:05:03 running: cmd.exe /c "C:\Program Files\OSGeo4W_v2\\etc\postinstall\setup.bat"

2) C:\Program Files\OSGeo4W_v2>textreplace -std -t apps/Python39/Scripts/f2py.exe

Version 0, edited 12 months ago by ascottwwf (next)

comment:15 by ascottwwf, 12 months ago

I've solved it! - (embarressed face)

What I failed to mention in the thread above is we use the Powershell App Deploy Toolkit (or PSADT) https://psappdeploytoolkit.com/ to wrap the installer. This is so we can install as system while giving the user visibility of the dialogs and a prompt to close the QGIS application if it is running when the install lands on their machine (we also use this so they have the opportunity to defer the install until later).
But as part of the PSADT install I had set it to block the execution of the QGIS executable "qgis-ltr-bin.exe" (or processname "qgis-ltr-bin"), which in itself is usually a good thing - to prevent them opening the app while the install is still in progress.

I think this was the cause of the problem, As during the OSGeo4W install the "qgis-ltr-bin" processname was being launched (or one by the same name) and this process was being blocked - causing the install to not entirely succeed.

So my fix was to remove the PSADT -BlockExecution switch and the install now succeeds Obviously (and unfortunately) we can't prevent our (impatient) users from relaunching the QGIS app before it has completed the install, but at least if they wait the install now completes without issue.

Sorry for wasting your time, although hopefully this thread may aid someone else with similar issues in the future.

comment:16 by jef, 12 months ago

Resolution: invalid
Status: newclosed
Note: See TracTickets for help on using tickets.