DLN 1.0 installation fail on Windows 10 - temporary workaround now found

[Dave Martin]

Hi Carla,

Regret that the new 1.0 installer (DLN100_Windows-installer-DB262.exe) still fails on virgin Windows 10 Pro (ver 21H1, with patches / updates to today's date).
Appears the installer is missing a component or relies on a superceded component.

Dave

[cdschroer]

Thanks for reporting this Dave - and I'm sorry you are experiencing so many problems.  We did test the installation on a few different machines that we have access to, including a brand new PC from the manufacturer, with only Photoshop installed in addition to what comes with the system. In other words there are no developer libraries or anything like that on it. This is a machine running Windows 10 pro - we didn't have any problems.

I have passed this on to the developer - who is traveling and won't be able to look at it for a few days.  Im also asking some other folks with Windows systems to try out the installation so we can see how wide spread the problem is.

I did a few searches, and this seems to be a somewhat common problem on Windows machines and many apps rely on this dll. For example - you can try to run Skype to see if you get the same error. It should be pre-installed on your system as part of the VisualC++ package.  You can learn more and try to solve this issue from this article: https://geeksadvice.com/fix-vcruntime140-dll-is-missing-error-on-windows/  - there is a method for "repairing" your Visual C++ 2015 Redistributable package that might do the trick - and seems pretty straightforward to try.

Thank you for your diligence and detailed reporting!  It really helps to get these kind of reports, since we aren't equipped with a test lab.

Carla

[Dave Martin]

Thanks Carla.

The Visual C++ runtime isn't part of a Windows installation; it is only installed by applications that need it. Re that new Windows 10 PC with just Photoshop you were using, which didn't have this problem - it may be that the necessary Visual C++ runtime was installed by the Adobe Photoshop installer. It is a commonly-reported issue as software authors assume it has already been installed - which it often has; including, I suspect, by Microsoft Office.

I don't know what CHI has used to write the DLN, but it may be that the runtime in question is not directly required by the actual top-level DLN, but it is a deeper dependency by a component used by DLN - e.g. a screen/graphics library, or a database driver - but in the end if it is really needed for DLN to run, the installer needs to check for its presence and install it if necessary.

Many of the suggestions on that web page you kindly linked to don't apply - they relate to repairing/fixing a defective already-installed runtime, whereas this is a case of it not being installed at all; and I have a healthy scepticism for third-party packages that offer to "fix your PC"! 

I have downloaded the runtime from from Microsoft already; I had held off in the hope of being able to verify a successful install using the DLN installer, but if its going to be some days before the developer can fix the installer, I will try a manual install of the Microsoft supplied package now.

Regards
Dave

[Dave Martin]

Slight progress but still not able to run DLN v1.0

On the bare Windows 10 machine (rolled back to restore point immediately before starting previous DLN installation attempts):

Downloaded Visual C++ 2015 64-bit installer from Microsoft https://www.microsoft.com/en-gb/download/details.aspx?id=48145
All installed OK. Checked for updates, rebooted.

Ran DLN installer - all ran to completion, no error messages.

Restarted PC, tried to start DLN - fails (pic below). Checked and verified Visual C++ 2015 runtime installed OK, tried using its own repair - no better.

Restored PC state and did it all over again, installing Visual C++ 2015 runtime, checking for updates, checking installation, installing DLN, check for updates again - DLN still crashes as below.

Dave
(p.s. sorry for size of pic - this forum now only allowing me to upload "Max total size: 14.59 kB" ! )

[cdschroer]

Thanks Dave for keeping at this!  The thing I found useful on that page was the suggestion to run the repair - given that's already built-in.  I agree that third party solutions seem dubious and I try to avoid them.  I'm primarily a Mac person, and we only have one PC in our studio at this point. 

I expect Erich to be able to look at this on Wednesday or Thursday.  I have had a few other people try out the install and they did not have problems.  

I think it's documented in one of the appendices - but our code is written in C++ and uses the open source qt libraries for the UI. In addition to installing our own copy of Postgres, we also use the exiftool for the inspector, and the Archiver tools and X3ML metadata tool are written in Java - so we do install our own copy of the Java Runtime Environment. I'm not sure where the dependency lies - as I don't write code at this point in my life. (And I'm thankful for that 😉)

Carla

[Dave Martin]

Thanks Carla.
I have run the 'repair', just in case, but that could only be run once the runtime in question was installed, as it isn't part of a Windows-10 installation. After that runtime is installed, running 'repair' has zero benefit in terms of the last-shown error.
I had seen, in various notes and, as you mention, on p.76 of the v1.0 user guide, that DLN uses a private copy of Postgres. I would be happy to run any instrumented code if Erich wants to help isolate where DLN is stopping. (I am familiar with software development - from writing embedded applications through to managing world-wide deployments ashore & afloat; regret though that I can't test Mac versions - my last Apple product was the 'Apple II' that I programmed in UCSD Pascal as part of my PhD research some 40 years ago!)

Dave

[Dave Martin]

Just reflecting a little more, I wonder if the 'private copy of Postgres' might be the clue? I could hypothesise that now we've at least got the installation to run to completion, if that install has put Postgres in a non-standard private location when installed, but the DLN code actually invokes (or tries to invoke) Postgres from its 'usual' location, then it could generate this type of error?

Dave

[Dave Martin]

Further update, after some more delving and testing this morning. 

1. Despite the DLN installer completing apparently without error (installing DLN, Postgres, and sample database), and setting up DLN icon in Start menu and on desktop as requested, and DLN now appearing in the list of Programs and Features' via Control Panel; there is no entry in 'Programs and Features' for Postgres.

2. There is no service installed on the PC for the Postgres server - stopped or otherwise. This is in contrast to PCs where the beta version was installed and ran OK.

3. Postgres is physically present on the PC though once the installer completes, albeit in a non-standard location - C:\Program files\CHI\pgsql folder, and if I then go down into pgsql\pgadmin4\bin I can run pgAdmin4

The above makes me increasingly suspicious that the attempt to make a discreet, self-contained, Postgres installation may be responsible for or contributing to the failure to run DLN after it is installed.

Dave

[Dave Martin]

Hi again,

More info / test possibility:

Have managed to repeat test on another PC (Win 10 Pro v21H1); exactly same symptoms: install fails at first / install the VC++ 2015 runtime from Microsoft / install then appears to work / DLN will still not run though (same error as last shown above).

As I have a great suspicion that these issues are because of the (possibly too) private Postgres installation, it could be instructive to also carry out a 'normal' Postgres installation on the test machine. Since the private installation doesn't register or become visible as an installed program, you cannot tell what version it is; so could Erich / team please advise exactly what version Postgres is needed and I will try a full normal install to see if that will allow DLN to run.

Dave

[Erich]

Hi Dave,

I'm sorry for the difficulties you have installing DLN. 

First, some information about how DLN etc is installed on Windows, assuming an initial installation:

1. Everything is copied to subfolders of "C:\Program Files\CHI\". I strongly suggest to keep the default installation location as proposed by the installer.

2. Hereafter, the following algorithm is executed depending on the installation options:

2a. It is checked, whether the DLN-database together with the postgres-Installation exist. The criterium used for that purpose is the existence of the database, which is located in %LOCALAPPDATA%\DLN. If that folder doesn't exist, the database will be initialized, postgres will be started and registered with Windows. Otherwise, step 2b is performed immediately.

2b. If the user has chosen to use the demo database or an empty database, the corresponding database backup will be restored.

After that, it should be possible to start DLN.

In case of missing database or postgres, you should uninstall DLN, and check

1. if postgres_DLN is still running. If so, stop the service

2. if %LOCALAPPDATA%\DLN exists. If so, delete folder DLN

You may also want to delete folder "C:\Program Files\CHI\" and its subfolders.

After a Windows restart, try installing DLN again.

Other possible causes for problems:

- Your Antivirus software could prevent executing the algorithm that initializes postgres.

I also suggest checking the contents of the following folders before and after installing DLN:

- C:\Program Files\CHI

- %LOCALAPPDATA%\DLN

Before installation, those folders should not exist, and postgres_DLN should not be running. After installation, both folders and their contents should exist.

Please let me know, if I could help you.

Erich

[Dave Martin]

Thanks for all that Erich,

To make sure cleanest test results, I'm just doing a bare-metal re-installation from scratch of Windows 10 Pro, basic install completed earlier today but LOTS of updates - drivers from Dell, and off course Microsoft updates; will report back ASAP.

Dave

[Dave Martin]

Hi again Erich / Carla,

Thanks for all the info above Erich, but regret still not able to run DLN. Have repeated tests on completely fresh Windows-10 Pro PC, including manually installing the Microsoft Visual C++ 2015 redistributable runtime, to no avail.

Have placed details & screenshots in document at https://www.dropbox.com/s/empvnrdp2i99q2f/DLN 1.0 - Windows-10 installation problems.pdf?dl=0

(sorry its on Dropbox, but as the forum is now preventing me uploading anything bigger than 3KB - which I know Carla is trying to rectify - I can't directly attach that PDF to this post).

Edit: Forgot to include in the PDF, but 'Running as Administrator' makes no difference, either during installation or when trying to run DLN.

Dave

 

[Erich]

Hi Dave,

According to various Internet forums, missing vcruntime140_1.dll seems to be a known problem. Although vcruntime140_1.dll is included in the DLN installation package (see C:\Program Files\CHI\pgsql\pgAdmin 4\python\vcruntime140_1.dll), it should also be registered, which is not covered by the DLN-installer (I'll have to look into that in more detail).

In the meantime, I suggest

1. uninstalling DLN completely, then

2. downloading and installing VC runtime as explained in the following video: 

3. installing DLN again

That should fix also similar problem with other missing files such as MSVCP140.dll and MSVCP100.dll

Good luck (and please keep me informed)

Erich

P.S.: There is another, more detailed article about that problem: https://is.gd/I1F3aT

[Dave Martin]

Thanks Erich,

If you look at the last page of the notes in that PDF I posted earlier today with all the screenshots, what is suggested in that video is exactly what I have done. I started with clean virgin Windows (no DLN etc.), downloaded and installed Microsoft Visual C++ 2015 redistributable run-time, rebooted, and re-ran DLN install - and DLN still won't run.

Dave

[Dave Martin]

hi again Erich,

I've just done a bit more investigating, following your last message which mentioned the location that, for example, VCRUNTIME140_1.dll was installed in. I have checked, and yes, the installer has placed it there. BUT if I search in the Registry - no sign of an entry for that DLL  It appears that the bespoke installer for the private copy of Postgres didn't register that DLL (and maybe not others either). I know that DLLs don't have to be registered, if the path is known and correct, but when DLN fails it doesn't mention where it is looking for, say, VCRUNTIME140_1.DLL  

(I had also, previously run the Microsoft 'System File Checker' ('sfc') tool just in case and that found no issues and made no difference).

As I said in one of the messages a few days ago, since the issues seem to be around how the private copy of Postgres is installed, if you could kindly please advise the exact version of Postgres that DLN is using, it could be instructive to try a generic/open/'normal' install of Postgres to see if that installs and makes available sufficient runtime for DLN to operate.

Regards
Dave

[Dave Martin]

Hi folks,

I've managed to do quite a bit more testing.

Have now tried on a total of four Windows-10 machines (3 Pro, 1 Home), none of which have had DLN or Postgres on before. The install failed on all of them. On each, manually installing the Visual C++ 2015 runtime redistributable, rebooting, and re-running the DLN installer meant that the installation ran without crashing; but DLN will still not run. Also, just out of interest, tested on a Windows 7-64 machine - exactly the same results.

From the documentation and other messages etc., have noted, thanks, that the intention is for a private installation of Postgres to avoid any conflicts (separate database, on a private port, with private copies of the Postgres binaries). However, I remain suspicious that this private installation is possibly connected with the problem - either 'something' not being installed or registered; or everything is being installed, but when DLN tries to run, it is maybe looking in the 'standard' location for a component, rather than in the private installation.

My enquiry about the version of Postgres used by DLN was not to run DLN on a different database, it was to see if a full 'normal' install of Postgres (as well) might provide the runtime necessary for DLN to start successfully.

So, I have taken a chance and downloaded the latest installer for Postgres (version 14.4-1) and tried installing that alongside where DLN has already been installed but won't run on a Windows-10 Pro machine.

That worked! - having a 'normal' Postgres set of binaries on the machine allowed DLN to start and run apparently OK, and open the sample database.

I have verified this was a repeatable effect on a second Windows-10 machine where just installing 'normal' Postgres 14.4-1 as well as DLN meant that a DLN which wouldn't start/run, now can. Just out of interest, I also tried on the Windows 7-64 machine where DLN was installed but wouldn't run - and having 'normal' Postgres installed meant that DLN would run.

I hope this helps point where the installation/installer issue lie, meantime, just installing Postgres 14.4-1 as well is a workaround.

Dave

[cdschroer]

Thank you Dave for all the hard work!  I was traveling for a bit and fell behind on the forums.  Even though we ran some tests on a couple of windows machines - we are primarily a Mac shop.  Erich tested in his environment as well - but something like not having the dll's properly registered could be an issue - as you noted at some point in this thread. I did test installation on a brand new machine running Windows 10 pro and with only Photoshop and Metashape installed - and it worked without problems.  

 

One last question for you - just so we understand all the variables.  When you did the install on a clean machine - did you choose the default location for the DLN install?

The amount of effort and due diligence you have put in on this is truly heroic.  Thank you for sticking with it. I hope that now that you have it running you will find it a useful tool.  We've been using it on some projects and even though there are a few features we didn't have time/budget to implement we are really happy with what is there and how much it does.

 

Carla

[Dave Martin]

Thanks Carla,

All the installations were on the default path.

Buried in the 7 pages of screenshots PDF I linked to* on 16th July, there were screenshots on page 2 (showing where DLN was asked to install) and page 3 (where DLN was actually installing) show it being installed in the default location.

* that was another one which I had to post on Dropbox as the forum still has the miniscule reduce balance for attachments (Carla - have updated private messages about this etc.)

Dave

[Erich]

Hi Dave and Carla,

I finally could reproduce the problem with the missing DLL. I had used a VM for testing on a minimal Windows 10 Pro machine. Although VCRuntime does not belong to the Windows installation, it was installed implicitly on my VM via VMtools (VMware). Therefore, I didn't have problems installing DLN.

Using "appwiz.cpl" on my VM, I could verify that VCRuntime (i.e. Microsoft Visual C++ 2015-2022 Redistributable...) was actually installed before installing DLN. I then explicitly uninstalled VCRuntime and rebooted. Hereafter, I installed DLN, and got the missing DLL error (same as Dave's error).

I then downloaded and installed "VC_redist.x64.exe" (https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170), and restarted Windows.

Then, I uninstalled DLN.

Finally, I re-installed DLN, and it worked.

The whole procedure is also described in detail in https://www.electronicshub.org/vcruntime140_1-dll-error-fix/#2_Uninstall_Reinstall_important_VC_Runtimes

I don't think, it is a good idea to integrate the above procedure in the DLN-Installer, as there would be complications and side effects for other applications relying on VCRuntime DLLs. It is probably better to provide the above information in the DLN installation manual, e.g. under "troubleshooting".

Erich

[Dave Martin]

Thanks Erich,

i'm sorry, but with respect I absolutely disagree. That may be a convenient way round the problem, but if you are supplying an installer, when it finishes it should have installed all necessary components. Any installation tool worth its salt should be able to handle dependencies, and check if any precursor packages/utilities/libraries needed are present, and if not, just install them.

Dave

[Erich Leisch]

I forgot to mention that VC_redist.x64.exe must be installed as Administrator. 

Erich 

[Dave Martin]

4 hours ago, Erich Leisch said:

I forgot to mention that VC_redist.x64.exe must be installed as Administrator. 

Erich 

Hi Erich, yes that makes sense - and indeed installing services (such as that installed for the dedicated Postgres) can often require that as well; so not uncommon for installers to check they're running with elevated access, and if not, abort the installation and ask the user to restart 'as administrator'.

Dave

[cdschroer]

Hi Dave -

Erich updated the installer so that it now includes the installer for the visual C++ runtime.  After a bit of testing by Erich and by me - it is now up on the downloads page.  It's the same link on the page - but it points to a file called DLN100_Windows-installer-DB262b.exe - where the b denotes this updated installation.  The DLN software itself and the demo database, etc are all the same as before.

We hope this solve the problem for most users.

Carla