Problem of Qt5Network.dll or Qt5Widgets.dll missing

TheCrowKaka

@hskoglund
I have a project where I create a DLL for using in vb.net or c# using ActiveQt. The project has been working fine uptill now.
A new development environment after getting dlls missing problem with existing environment.
Windows 7.
qt5.10.1 msvc 32bit installation.
msvc community version 2015.
The soucecode of the DLL when compiled with qt, is compiled well and a DLL is created.
Using windeployqt i gather all the files required for the DLL... all OK.
I also put 3 more files as per instructions on website for deployment of msvc based qt projects.
I use regsvr32 to register the DLL... i get registered OK message.
I start a new project in visual studio vb.net and add a reference to the dll. The reference is added successfully.
I run the application. At the statement where I initialise the class object from the DLL, I get the following error message.
"The program cant start because Qt5Network.dll is missing from your computer. Try reinstalling the program to fix this problem."

I try to compile already released sourcecode, successfully deployed, and I still get the same message with Qt5Widgets.dll missing.
I think I am missing some step of installation in creating the environment. Can you please help?

koahnig

@TheCrowKaka

Where are those missing dlls found?
Respectively are other dlls directly stored with your self-created dll?

TheCrowKaka

@koahnig
All the DLLs are gathered in the folder where my dll is located. I used the windeploy tool to do that.

koahnig

@TheCrowKaka

When Qt5Network.dll is already in the same folder as your self-created dll, it seems to be a path issue with vb.net.
Note, that is completely outside of my experience. However, you may try to add the folder of dlls to PATH environment.

BEWARE that comes the danger that other things are messed up. Therefore, I recommend only a work around for testing if it would solve the problem.

TheCrowKaka

@koahnig @hskoglund
One more observation, I already have one compiled DLL which was released to customers. If I include that DLL in the vb.net project, I do not get the Qt5Widgets.dll missing problem.
However, If I compile the same sourcecode now, I get the problem for the newly compiled DLL.

TheCrowKaka

@koahnig
As you say, it might be a path problem with vb.net, I though of that. However, if that is the case, how is it that it does not give this error with the DLL compiled earlier on another development machine, where the files and folder structure is same. If it was a path problem, then it should give error even in this case. So for the same vb.net application, I just change refeence to the older DLL, it works and i change reference to the new DLL, it does not work.

JKSH

@TheCrowKaka said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

@koahnig @hskoglund
One more observation, I already have one compiled DLL which was released to customers. If I include that DLL in the vb.net project, I do not get the Qt5Widgets.dll missing problem.
However, If I compile the same sourcecode now, I get the problem for the newly compiled DLL.

Use your "good" DLL to launch your vb.net application. While the application is running, use ListDLLs (https://docs.microsoft.com/en-us/sysinternals/downloads/listdlls ) to print the absolute path to all loaded DLLs.
Shut down the application.
Replace your "good" DLL with the "bad" DLL. Now, try to launch your vb.net application again. When the error dialog is open ("The program can't start because..."), run ListDLLs again.

Compare the two lists. What differences do you see?

@TheCrowKaka said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

how is it that it does not give this error with the DLL compiled earlier on another development machine, where the files and folder structure is same.

When you install Qt on a development machine, the absolute path to the dev folder is embedded into the Qt DLLs. This embedded path makes the DLLs search the dev folder for dependencies.

windeployqt removes these embedded paths.

koahnig

@JKSH said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

When you install Qt on a development machine, the absolute path to the dev folder is embedded into the Qt DLLs. This embedded path makes the DLLs search the dev folder for dependencies.

windeployqt removes these embedded paths.

Really? Are you sure about that?

TheCrowKaka

@JKSH @koahnig @hskoglund
Now, even the good DLL has stopped working in this environment. So could not try the listdlls.
How can we ensure that the application or DLL finds the qt dlls in its own folder?

TheCrowKaka

@JKSH @koahnig @hskoglund
I even tried creating another new environment with Qt5.8 and MSVC 2015 community edition. I remember the last time I did that, it was just installing the two packages, compiling the code in Qt5.8 and using the Dll.
Desperately need some help here.
If there are any environment variables to be set, what are they?

JKSH

@TheCrowKaka said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

Now, even the good DLL has stopped working in this environment. So could not try the listdlls.

Find an environment where the good DLL works, and run ListDLLs there. (Do you have another development machine?)

How can we ensure that the application or DLL finds the qt dlls in its own folder?

I don't have experience with regsvr32 or VB.net so I don't know what it does behind-the-scenes.

Normally, I just build my application and put the Qt DLLs in the same folder as the .exe. Normally, I don't register anything or set any environment variables at all.

@koahnig said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

@JKSH said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

When you install Qt on a development machine, the absolute path to the dev folder is embedded into the Qt DLLs. This embedded path makes the DLLs search the dev folder for dependencies.

windeployqt removes these embedded paths.

Really? Are you sure about that?

Yes. @hskoglund explained it in more detail at https://forum.qt.io/topic/66480/deploy-on-windows

koahnig

@JKSH

After your post I have checked Qt5Gui.dll for Qt5.10.1 which did not hold the install path.
This is limited to Qt5Core.dll and is also true for MinGW pre-built.

So far I have never used windeployqt. So in general the install path in there is always an issue. However, I am typically staying Qt5.4 and this might have changed with Qt5.5 since this seems to be a reference in his post.

Thanks for this important detail. Hopefully, I remember when entering into trouble there.

TheCrowKaka

@JKSH @hskoglund
Well, I could finally get the list of dlls used using listdlls64. Here is the output.
In order to get the list, I have done the following.
I just installed the Setup of my DLL package (already released to the customers) on a clean environment where I have Windows 7 &VS15. I have not installed Qt in this machine.
Then I created a dummy application and initialised the DLL in Form Load. It passed without giving any problem. So while that was running,
If I just run listdlls64 -d newCosmic_17.dll, I dont get anything. It just says access denied.
So I just run listdlls64 >data.txt and got the output in this txt file. This is what is the output I got for the dummy program executable that is running in the background.

WindowsApplication1.vshost.exe pid: 3976
Command line: "c:\users\kaushik2017\documents\visual studio 2015\Projects\WindowsApplication1\WindowsApplication1\bin\Debug\WindowsApplication1.vshost.exe"

Base Size Path
0x0000000000dd0000 0x8000 c:\users\kaushik2017\documents\visual studio 2015\Projects\WindowsApplication1\WindowsApplication1\bin\Debug\WindowsApplication1.vshost.exe
0x0000000077a30000 0x1a9000 C:\Windows\SYSTEM32\ntdll.dll
0x00000000753a0000 0x3f000 C:\Windows\SYSTEM32\wow64.dll
0x0000000075340000 0x5c000 C:\Windows\SYSTEM32\wow64win.dll
0x0000000075330000 0x8000 C:\Windows\SYSTEM32\wow64cpu.dll
0x0000000000dd0000 0x8000 c:\users\kaushik2017\documents\visual studio 2015\Projects\WindowsApplication1\WindowsApplication1\bin\Debug\WindowsApplication1.vshost.exe
0x0000000077c10000 0x180000 C:\Windows\SysWOW64\ntdll.dll
0x00000000751e0000 0x4a000 C:\Windows\SysWOW64\MSCOREE.DLL
0x0000000075df0000 0x110000 C:\Windows\syswow64\KERNEL32.dll
0x0000000075d90000 0x47000 C:\Windows\syswow64\KERNELBASE.dll
0x0000000075cf0000 0xa0000 C:\Windows\syswow64\ADVAPI32.dll
0x0000000076030000 0xac000 C:\Windows\syswow64\msvcrt.dll
0x0000000076010000 0x19000 C:\Windows\SysWOW64\sechost.dll
0x0000000075aa0000 0xf0000 C:\Windows\syswow64\RPCRT4.dll
0x00000000755a0000 0x60000 C:\Windows\syswow64\SspiCli.dll
0x0000000075590000 0xc000 C:\Windows\syswow64\CRYPTBASE.dll
0x00000000750d0000 0x79000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscoreei.dll
0x0000000075f40000 0x57000 C:\Windows\syswow64\SHLWAPI.dll
0x00000000761f0000 0x90000 C:\Windows\syswow64\GDI32.dll
0x0000000075600000 0x100000 C:\Windows\syswow64\USER32.dll
0x0000000075710000 0xa000 C:\Windows\syswow64\LPK.dll
0x0000000076580000 0x9d000 C:\Windows\syswow64\USP10.dll
0x0000000075a40000 0x60000 C:\Windows\SysWOW64\IMM32.DLL
0x0000000076110000 0xcc000 C:\Windows\syswow64\MSCTF.dll
0x00000000750c0000 0x9000 C:\Windows\SysWOW64\VERSION.dll
0x0000000074300000 0x6b1000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
0x0000000075230000 0xf5000 C:\Windows\SysWOW64\MSVCR120_CLR0400.dll
0x00000000700c0000 0x114a000 C:\Windows\assembly\NativeImages_v4.0.30319_32\mscorlib\225759bb87c854c0fff27b1d84858c21\mscorlib.ni.dll
0x0000000073d50000 0x13000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll
0x0000000073c00000 0x7e000 C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll
0x00000000759b0000 0x8f000 C:\Windows\syswow64\OLEAUT32.dll
0x0000000075b90000 0x15c000 C:\Windows\syswow64\ole32.dll
0x00000000717f0000 0x987000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System\52cca48930e580e3189eac47158c20be\System.ni.dll
0x000000006ff30000 0x18e000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Drawing\646b4b01cb29986f8e076aa65c9e9753\System.Drawing.ni.dll
0x000000006f2d0000 0xc5b000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Windows.Forms\5aac750b35b27770dccb1a43f83cced7\System.Windows.Forms.ni.dll
0x000000005a400000 0x1b000 C:\Program Files (x86)\Common Files\Microsoft Shared\VS7Debug\14.0\Microsoft.VisualStudio.Debugger.Runtime.Impl.dll
0x00000000716a0000 0x3000 C:\Windows\SysWOW64\api-ms-win-core-synch-l1-2-0.DLL
0x0000000076280000 0x83000 C:\Windows\syswow64\CLBCatQ.DLL
0x0000000074ac0000 0x16000 C:\Windows\SysWOW64\CRYPTSP.dll
0x00000000742c0000 0x3b000 C:\Windows\SysWOW64\rsaenh.dll
0x0000000074ab0000 0xe000 C:\Windows\SysWOW64\RpcRtRemote.dll
0x0000000074260000 0x5f000 C:\Windows\SysWOW64\SXS.DLL
0x00000000773e0000 0x5000 C:\Windows\syswow64\psapi.dll
0x000000006e7c0000 0x72f000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Core\55560c2014611e9119f99923c9ebdeef\System.Core.ni.dll
0x0000000068700000 0x77d000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Data\032f5fa875be86b577722ddeeee2e51c\System.Data.ni.dll
0x00000000683c0000 0x338000 C:\Windows\Microsoft.Net\assembly\GAC_32\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll
0x0000000075730000 0x35000 C:\Windows\syswow64\WS2_32.dll
0x0000000075700000 0x6000 C:\Windows\syswow64\NSI.dll
0x0000000077290000 0x11d000 C:\Windows\syswow64\CRYPT32.dll
0x0000000075720000 0xc000 C:\Windows\syswow64\MSASN1.dll
0x000000006ba00000 0x70c000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Xml\d86b080a37c60a872c82b912a2a63dac\System.Xml.ni.dll
0x0000000068e80000 0x62000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Xml.Linq\0261f24b2fd53085823ea90b359d71ee\System.Xml.Linq.ni.dll
0x000000005a140000 0x1cb000 C:\Windows\assembly\NativeImages_v4.0.30319_32\Microsoft.V9921e851#\7ca6a7b9413844e82108a9d62f88a2d9\Microsoft.VisualBasic.ni.dll
0x0000000071340000 0x80000 C:\Windows\SysWOW64\uxtheme.dll
0x000000005f6a0000 0x84000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\comctl32.dll
0x0000000074230000 0x13000 C:\Windows\SysWOW64\dwmapi.dll
0x0000000051780000 0xc5000 C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Runt73a1fc9d#\647f9e8a4465888d8348c3f66611c463\System.Runtime.Remoting.ni.dll
0x00000000713d0000 0x190000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.17514_none_72d18a4386696c80\gdiplus.dll
0x0000000073e80000 0x19e000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
0x0000000051620000 0x15c000 C:\StampSoft2017_SDK\newCosmic_17.dll
0x00000000511e0000 0x439000 C:\StampSoft2017_SDK\Qt5Widgets.dll
0x0000000050ce0000 0x4f1000 C:\StampSoft2017_SDK\Qt5Gui.dll
0x0000000050830000 0x4a8000 C:\StampSoft2017_SDK\Qt5Core.dll
0x0000000050810000 0x12000 C:\Windows\SysWOW64\MPR.dll
0x0000000064a20000 0x11000 C:\Windows\SysWOW64\NETAPI32.dll
0x000000006adb0000 0x9000 C:\Windows\SysWOW64\netutils.dll
0x0000000064a00000 0x19000 C:\Windows\SysWOW64\srvcli.dll
0x000000006adc0000 0xf000 C:\Windows\SysWOW64\wkscli.dll
0x0000000075f20000 0x17000 C:\Windows\syswow64\USERENV.dll
0x0000000075f00000 0xb000 C:\Windows\syswow64\profapi.dll
0x0000000076620000 0xc4a000 C:\Windows\syswow64\SHELL32.dll
0x0000000068290000 0x32000 C:\Windows\SysWOW64\WINMM.dll
0x00000000715b0000 0x6d000 C:\Windows\SysWOW64\MSVCP140.dll
0x0000000073b70000 0x15000 C:\Windows\SysWOW64\VCRUNTIME140.dll
0x0000000073ce0000 0x4000 C:\Windows\SysWOW64\api-ms-win-crt-runtime-l1-1-0.dll
0x00000000716d0000 0xdc000 C:\Windows\SysWOW64\ucrtbase.DLL
0x0000000073b60000 0x3000 C:\Windows\SysWOW64\api-ms-win-core-timezone-l1-1-0.dll
0x00000000716c0000 0x3000 C:\Windows\SysWOW64\api-ms-win-core-file-l2-1-0.dll
0x00000000716b0000 0x3000 C:\Windows\SysWOW64\api-ms-win-core-localization-l1-2-0.dll
0x0000000071690000 0x3000 C:\Windows\SysWOW64\api-ms-win-core-processthreads-l1-1-1.dll
0x0000000071680000 0x3000 C:\Windows\SysWOW64\api-ms-win-core-file-l1-2-0.dll
0x0000000071670000 0x4000 C:\Windows\SysWOW64\api-ms-win-crt-string-l1-1-0.dll
0x0000000071660000 0x3000 C:\Windows\SysWOW64\api-ms-win-crt-heap-l1-1-0.dll
0x0000000071650000 0x4000 C:\Windows\SysWOW64\api-ms-win-crt-stdio-l1-1-0.dll
0x0000000071640000 0x4000 C:\Windows\SysWOW64\api-ms-win-crt-convert-l1-1-0.dll
0x0000000071620000 0x3000 C:\Windows\SysWOW64\api-ms-win-crt-locale-l1-1-0.dll
0x0000000071630000 0x5000 C:\Windows\SysWOW64\api-ms-win-crt-math-l1-1-0.dll
0x00000000715a0000 0x5000 C:\Windows\SysWOW64\api-ms-win-crt-multibyte-l1-1-0.dll
0x0000000071590000 0x3000 C:\Windows\SysWOW64\api-ms-win-crt-time-l1-1-0.dll
0x0000000071580000 0x3000 C:\Windows\SysWOW64\api-ms-win-crt-filesystem-l1-1-0.dll
0x0000000071570000 0x3000 C:\Windows\SysWOW64\api-ms-win-crt-environment-l1-1-0.dll
0x0000000071560000 0x3000 C:\Windows\SysWOW64\api-ms-win-crt-utility-l1-1-0.dll
0x0000000050710000 0xf2000 C:\StampSoft2017_SDK\Qt5Network.dll
0x000000006ad00000 0x44000 C:\Windows\SysWOW64\DNSAPI.dll
0x000000006ad60000 0x1c000 C:\Windows\SysWOW64\IPHLPAPI.DLL
0x000000006ad50000 0x7000 C:\Windows\SysWOW64\WINNSI.DLL
0x00000000506e0000 0x29000 C:\StampSoft2017_SDK\Qt5Xml.dll
0x00000000505b0000 0x122000 C:\StampSoft2017_SDK\platforms\qwindows.dll
0x0000000050580000 0x24000 C:\StampSoft2017_SDK\styles\qwindowsvistastyle.dll

Now, the next part, I unregistered the component, copied the newly compiled component in that same directory and registered that component.
Then included that new component in the dummy program.
The Dummy program seemed to work... means, it went past the initialisation happening in the Form_Load, but when I pressed the button, it just gave an exception and the component mymachine was Nothing.
In short, it did not give the dll missing error but it did not get initialised.

The Code of my vb.net dummy program is as given here... FYI.

Public Class Form1
    Public WithEvents mymachine As newCosmic171Lib.NewCosmic17
    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Dim retval As Integer
        retval = mymachine.ConnecttoMachine("192.168.1.60")
    End Sub

    Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
        mymachine.DisConnect()
    End Sub

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        mymachine = New newCosmic171Lib.NewCosmic17
    End Sub

    Private Sub mymachine_ErrorEmitted(p_ErrNum As Integer, p_ErrDescript As String) Handles mymachine.ErrorEmitted
        Label2.Text = p_ErrDescript
    End Sub

    Private Sub mymachine_MachineState(p_isConnected As Boolean) Handles mymachine.MachineState
        If p_isConnected = True Then
            Label1.Text = "Connected"
        Else
            Label1.Text = "Disconnected"
        End If
    End Sub
End Class

TheCrowKaka

@JKSH @hskoglund
And another observation.
When I install by DLL setup on the machine where I am compiling the sourcecode, the installed DLL does not work with this dummy application.
It gives the error of Qt5Network.dll missing.

hskoglund

Hi, first about those errors re. missing Qt dlls::
if you don't put the Qt dlls in the same directory as the .exe file ( c:\users\kaushik2017\documents\visual studio 2015\Projects\WindowsApplication1\WindowsApplication1\bin\Debug) then you need to add the directory where they are ( C:\StampSoft2017_SDK) to your PATH setting.

Then about the C:\StampSoft2017_SDK\newCosmic_17.dll not loading correctly into your Dummy VB.net program: you're correct to first do regsvr32/u newCosmic_17.dll on the old DLL and then doing regsvr32 newCosmic_17.dll on the new one. However the loading into vb.net can still fail because the registry is easily cluttered with multiple incarnations of newCosmic_17.dll registrations pointing to lost/forgotten versions.

Easiest way to sidestep the clobbered registry syndrome is to rename the DLL when you rebuild it, so that the new one is called newCosmic_18.dll. Then when you do regsvr32 on it you can be sure that the entry is unique :-)

jsulm

@hskoglund I would not set PATH as it can break other Qt applications. There is qt.config file where one can set needed paths.

TheCrowKaka

@hskoglund
I have all the Qt dlls in the same directory as the .exe file. I am running the windeploy to collect all the dlls in the exe directory. So I dont think i need to set the Path.
Secondly, in the vb.net dummy program, each time i am registering the dll, I am able to see the COM component and add that COM component as a reference in vb.net program.
However, at this line

mymachine = New newCosmic171Lib.NewCosmic17

in the Form1_Load event, it gives this error of Qt5Network.dll missing.

hskoglund

Hi, the qt.conf file is for telling Qt where to find its plugin DLLs (for example, platforms\qwindows.dll), it has no effect on the loading/finding of dlls like Qt5Network.dll or Qt5Widgets.dll (which is done by Windows, not Qt).

Changing the PATH is not a good solution (as you say) it is best to put all the needed Qt dlls in the same directory as the .exe file.

If you still get errors like Qt5Network.dll is missing when you New up the newCosmic_17.dlll, it's most likely because you used windeployqt to install the Qt dlls. What I mean, windeployqt is a good program which normally installs every Qt dll that is needed. However it has a blind spot, it does not analyze the .exe file for which other dll it might load, in your case thenewCosmic_17.dll.

So if newCosmic_17.dll has a dependency on some Qt dll that your main .exe does not (like Qt5Network.dll), then windeployqt will be blissfully unaware of that dll and not install it, and you will get the error that Qt5Network.dll is missing.

Easiest workaround is to remember, after every time you've run windeployqt, also manually copy the Qt dlls that are needed by newCosmic_17.dll. Then your New of newCosmic_17.dll should work fine :-)

TheCrowKaka

@hskoglund
well, I still dont have a solution for the actual problem.
However because @JKSH asked me to do the listdlls listing of dlls, I created an environment without Qt but with just Visual Studio, I found a way out.
Now I am coding on one machine (where I still get the problem) and testing on this other machine without Qt where I dont get the problem of Qt5Network.dll missing. Atleast my work has proceeded for the time being.
One thing however which I was missing even on this new machine was actually registry cleanup, which I did and things started working on the new testing environment.
I will mark this thread solved for now.
Thanks all of you for your inputs.

JKSH

@TheCrowKaka said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

Now, even the good DLL has stopped working in this environment. So could not try the listdlls.

You can use ListDLLs even if the application doesn't load fully.

Try to run your app.
Wait until the error dialog appears ("The program can't start because..."). Do not close the dialog yet.
Run ListDLLs while the error dialog is open.

@TheCrowKaka said in Problem of Qt5Network.dll or Qt5Widgets.dll missing:

well, I still dont have a solution for the actual problem.

Run ListDLLs on the machine which has the problem. Compare the result with your "good" machine. Which folder is Qt5Core.dll loaded from?