vcruntime140_1.dll deleted on Wireshark update/install

Possibly related to a reported vcredist issue.

The Wireshark installer doesn't touch the vcredist components itself, it just runs the vcredist installer.

Hello Graham! Thank you for you answer! In this case, a Wireshark update/kit that contains the latest vcredist installer should be provided, right?

If this is the cause of the issue, that will require the builders to run the 16.10.4 version of Visual Studio to pick up the latest vcredist. I think they're currently running 16.9.3

According to the Visual Studio updater the Windows package builders were running 16.10.1. I upgraded them to 16.10.4.

I based my comment on the builders output from the pipelines, e.g. from pipeline #343044185.

**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.9.3
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************

$ cmake -G "Visual Studio 16 2019" -A x64 -DENABLE_LTO=off ..
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.17763.
-- The C compiler identification is MSVC 19.28.29913.0
-- The CXX compiler identification is MSVC 19.28.29913.0

MSVC 19.28 is 16.8 or 16.9

On my VS 19.10.4 system I get:

**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.10.4
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************

-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
-- The C compiler identification is MSVC 19.29.30040.0
-- The CXX compiler identification is MSVC 19.29.30040.0

Ah, OK. The merge request builder uses a Docker image which hasn't been updated in a while.

You can fix the symptom by running the installer with /repair option:

[Wireshark-dev] Visual C++ 2019 redistributable - giveth and taketh

Where can people find the installer?

I assume I grabbed it from my development system. Was 2019 then. Now 2022.

https://www.wireshark.org/lists/wireshark-dev/202106/msg00018.html

-- Using C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Redist\MSVC\14.29.30036\vcredist_x64.exe for the NSIS installer.

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC>dir /s *.exe
 Volume in drive C has no label.
 Volume Serial Number is 8A42-39DB

 Directory of C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\14.34.31931

11/29/2022  07:22 PM        25,466,016 vc_redist.x64.exe
11/29/2022  07:22 PM        13,833,056 vc_redist.x86.exe
               2 File(s)     39,299,072 bytes

 Directory of C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Redist\MSVC\v143

11/29/2022  07:22 PM        25,466,016 vc_redist.x64.exe
11/29/2022  07:22 PM        13,833,056 vc_redist.x86.exe
               2 File(s)     39,299,072 bytes

     Total Files Listed:
               4 File(s)     78,598,144 bytes
               0 Dir(s)   4,853,673,984 bytes free

Or maybe here: https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170

BRO I M NOT GEETING WIRESHARK

Given that the Visual C++ redistributables occasionally have bugs like this, I wonder if it would make sense to ship the DLLs directly, aka Local Deployment. It looks like we might be able to discover the runtime DLLs InstallRequiredSystemLibraries. One of the arguments against doing that is that is that Windows can't automatically update locally deployed DLLs, but we're pretty aggressive about pushing out updates.

Never mind. I forgot where the FSF draws this particular line.

I assume that statically linking our libraries with the VC runtime is Right Out, as it means we're shipping an executable some of the instructions of which would be from non-GPL (but source-available, as far as I know, with the source provided as part of VC) libraries.

I.e., I assume the only thing you can do to ship windows binaries of a GPLed program is to ship an installer program/script that will install the VC runtime, and run that program as part of the installation process for your program.

How does the Universal CRT affect this? "Introducing the Universal CRT", from 2015, indicates that

[Microsoft] had split the CRT into two logical parts: The VCRuntime, which contained the compiler support functionality required for things like process startup and exception handling, and a “stable” part that contained all of the purely library parts of the CRT, which we would service in-place in the future rather than releasing newly versioned DLLs with each major version of Visual Studio. At the time, this “stable” part took the form of two libraries: the AppCRT and the DesktopCRT (the release DLLs were named appcrt140.dll and desktopcrt140.dll).

and that

The VCRuntime still exists in the same form and with equivalent contents as in previous CTPs. It’s in the “stable” part that we’ve made major changes in this latest CTP6. The AppCRT and DesktopCRT have been recombined into a single library, which we have named the Universal CRT. The new DLLs are named ucrtbase.dll (release) and ucrtbased.dll (debug); they do not include a version number because we’ll be servicing them in-place.

The Universal CRT is a component of the Windows operating system. It is included as a part of Windows 10, starting with the January Technical Preview, and it is available for older versions of the operating system via Windows Update.

For what it's worth, I just now updated the Wireshark on my Windows 10 VM to Wireshark 3.4.7 from 3.4.6, and if I try to launch Wireshark, it complains that MSVCP140.dll was not found.

I uninstalled 3.4.6 as part of the update.

If I try to fix the problem by uninstalling 3.4.7, and then downloading the installer and re-installing it, the problem is still there; the installer appears not to be installing the DLL in question.

Do the recent automated builds fix the issue? 3.4.7 was built with Visual C++ 16.10.1, which shipped with a faulty vcredist according to the link in the first comment. Recent automated builds were built with Visual C++ 16.10.4, which should ship with a working vcredist.

A recent 3.4.8 automated build works.

A recent 3.4.8 automated build works.

...and appears to leave the system in a state where, not only can I install 3.4.7 on top of the 3.4.8 build, I can then uninstall 3.4.7, install 3.4.5, update to 3.4.7, and the updated-to 3.4.7 works.

I guess it sticks (because the new installer sticks around?).

mentioned in issue #17513 (closed)

Hey, BTW, can we sowehow get rid of installing vcredist.exe? Like an optional flag in installer?? It is so effing slow. It is crazy. And yeah I cannot reproduce it, vcruntime140_1.dll is there. An was always there, but then again, I don't install all nightlies anymore :)

Nope, it's required for Wireshark to run.

But I already have all version 2015-2019 installed, always had. I mean just like with directx9 installer there should be a flag to not do /quit (re?)install every time, because it is too slow. Or do we need to have latest version of them too every time?

How long does it take on your systems?

As we don't move the version on too often, mostly its a quick run that reports a return code of 1638 indicating it's not newer than the currently installed version. For me, using an up to date Win 10, this is less than a second.

Obviously if there's a new version to be installed that does take some time.

For me, using an up to date Win 10, this is less than a second

I doubt it depends on Windows version, 21H1 here. It is like 60 seconds here or more, while everything else in installer is like 10 seconds.

mostly its a quick run that reports a return code of 1638 indicating it's not newer than the currently installed version

What happens if the version is the same?

I'm also running 21H1, I haven't been able to check what happens with the same version as currently I have 14.29.30133 installed and the latest installer I have from my VS installation is 14.29.30036. MS seem to be having difficulties as I can't access their latest VC ++ downloads page to get the newest installer.

mentioned in issue #17538 (closed)

marked #17538 (closed) as a duplicate of this issue

marked this issue as related to #17538 (closed)

closed

vcruntime140_1.dll deleted on Wireshark update/install

Summary

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Sample capture file

Relevant logs and/or screenshots

Build information

Child items ...

Activity

vcruntime140_1.dll deleted on Wireshark update/install

Summary

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Sample capture file

Relevant logs and/or screenshots

Build information

Relates to

Activity