What are known causes for VB6 run-time Error 372 - Failed to Load Control Your version of may be outdated.
I have a activceX control built from several standard windows controls and a Far Point.
The control is used in a VB6 desktop application. The behavior I am seeing is that this active control fails occasionally on some workstations. I have confirmed that the correct references are on the workstations. The odd part is, the control will not fail right away. It will work correctly on the Main form but fails when another form is opened.
It seems to be also tied with run-time 7 out of memory error. When these errors typically occur no unusual CPU or memory usage is shown in Task Manager.
Seems the issue may related to MSCOMCT2.OCX.
Any ideas.
First open up your form files (the file with the extension of FRM) in NOTEPAD makes sure the forms are truly referencing the same ActiveX Control. The references are near the top of the form. It is possible though uncommon that VB6 will mismatch the references between different forms.
Second look at this from Micrsoft. Make sure that the control is installed for All users and see if your problem goes way.
Problems like this are usually caused by a mismatch between the expected COM interface and the control that is loading.
I had the same problem and found that when I created my installation package (using InstallShield) that I needed to uncheck the "Filter Files" box in the dialog where INstallShield is setting up to scan the Visual Basic project for dependencies. It was not packaging a MSDatgrd.ocx control of the VB Project into the setup, and that control was not in the Win 7 machine, so it threw this 372 message.
When I rebuilt my installation package for my software, and had it not filter files, it included that control and installed it on the target machine as part of the setup process and everything ran just fine.
Related
Get a Unity project with a native low-level plugin .. Mac version.
Make a small change in the Xcode plugin project, and build.
You now have the new plugin library in the Unity project.
If you "Build" again, the final Mac app of course now contains the new library - no problem.
However .....
if you hit Play in the Editor,
it does not pick up the change in the library.
In fact it seems:
Every time you change a library in Unity, you must restart Unity!
Everything has been tried, "Reimport all assets", AssetDatabase.Refresh, renaming, etc etc. It seems you literally must restart Unity.
What's the deal on this?
More information on this:
It would seem that mac shared libraries/bundles cannot be unloaded. Article:
https://docstore.mik.ua/orelly/unix3/mac/ch05_03.htm
Apparently this was fixed in 10.5:
https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/dlclose.3.html
Maybe Unity could solve this now. At their usual pace it should happen anytime around 2035.
Sadly it comes down to you can't do anything about it.
As per .net's DLL handling DLL's cannot be unloaded individually without closing the application domain. And while Unity picks up the changes done to the DLL the old version is kept in memory and used at runtime in the editor. A "funny" thing you can do to see this in action is by deleting the native plugin from within the editor. Confirm that you want to delete the file. The file will dissapear from the inspector. However if you right click the folder and refresh (ctrl+r) you will see that the file gets reconstructed (this also happens when hitting "re-import all", as the application domain isn't closed, despite unity restarting).
When building the application it will however use the locally stored file, and not the memory stored file. Hence the plugin being updated on the build.
There is no way to unload an individual assembly without unloading all of the application domains that contain it. Even if the assembly goes out of scope, the actual assembly file will remain loaded until all application domains that contain it are unloaded.
source
This has been a problem for some time now, and people have made attempts for work arounds and/or fixes, but as far as I am aware the "work arounds" that exist now are for windows only. here are some links to discussions about it.
"Unload a plugin"
"Reloading native plugins"
I suppose something that could be done is writing a wrapper that automatically restarts Unity when the dll has been edited... Although this won't solve the issue it'll atleast make it somewhat less of a hassle.
I modified my vb6 project to support unicode by using CyberActiveX UniListView100 (UniListView.ocx) controller. I updated my listview with uniListview and project is working well on my machine. But when I try to run it on another machine, it is giving 'Error in Loading DLL' error right after I click on the 'Step into' or 'Start' button.
Once I tried with VB Common Controls Replacement 1.4 Library and the similar scenario happened there as well, code is only running on the machine where it created. But all machines I tried to run this code are equally set-up.
What can be the cause of this error? I even have registered the UniListView.ocx file in the Windows/SysWOW64 folder.
I tried to identified what is happening here with Microsoft Process Monitor, but I was unable to find anything from its logs yet.
Please tell me what can be the cause for this..
Often, the DLL in question is a dependency of the DLL you're trying to load. Find and use the Depends utility to see who requires what. You run Depends, Depends runs your process. First run it on your machine, then on a failing machine. The differences are usually obvious.
while doing the build of my dontnet 4.0 project setup i'm getting following errors
An error occurred generating a bootstrapper: Unable to finish updating resource for E:\project\Setup\Debug\setup.exe with error 8007006E E:project\Setup\Setup.vdproj Setup
General failure building bootstrapper E:\project\Setup\Setup.vdproj Setup
Unrecoverable build error E:\project\\Setup\Setup.vdproj Setup
I am using dotnet framework 4 and MSVS 2010.
This happens because The .NET framework version required by the setup project is different than the .NET framework version targeted by the application.
To change verify this:
In Solution Explorer, click the Setup project.
On the View menu, point to Editor, and then click Launch Conditions.
Click .NET Framework.
In the Properties window, change the Version property to the version of the .NET Framework that you want the Setup project to check for and install.
And also you need to Make sure that the Setup.exe program also checks for and installs the correct version of the .NET Framework.
Right click on the setup project -> Properties -> Prerequisites -> Select the correct ones.
When I turn McAfee real-time scan off, it works. I spent 2 hours on figuring this out :(
I googled a lot on this issue after trying all i just disabled my antivirus(NPAV) and this issue was solved.
turning off mcafee real time scanning worked for me as well on Windows 8.1
Here is yet another solution, this one is unlike the rest...
We recently added NTFS replication to our build tree root to provide some additional data redundancy and to begin to sync our old build machine with the new server. The NTFS replication caused some projects to fail with the exact same three error reported, and yet other projects work just fine. Set the replication on only run at night and the problem stopped occurring...
K
I got the same error when I changed targeted framework to 4.0 but neglected to change prerequisits for click once from 3.5 to 4.0 as well.
Fixing prerequisits resolved the problem.
Instead of disabling the Anti-Virus, I would suggest to just create an exclusion for your Solution Folder. See documentation if you are using Windows Defender. Microsoft Support
I've just had this same error and then realised Dropbox was running. I closed Dropbox and then the build completed successfully.
Thank you qwerty13579! How stupid of me, the solution is obvious. I have tried all sorts of things suggested over the internet, and even with the most recent version of VS Community 2017 (15.9.9), the bootstrapper failure pops up erratically, but with increasing frequency, to the point of frustration this past week. The principle: It doesn't succeed reliably, so it also doesn't FAIL reliably. The solution: Click the Publish Now button and watch the output panel. When it's that clear that it's failing, click the Publish Now button again immediately. Keep at it until it succeeds! Each round only takes a couple of seconds, much less time that it takes to re-build, take down anti-virus, and all that fancy stuff.
In my case, I traced the problem to an incorrectly dated setup.exe file in the bin\Release\app.publish folder of my application. When it fails, Publish Now creates an setup.exe that's two years earlier than the current day. When it succeeds, the setup.exe file is correctly dated.
Got the same problem. I disabled Windows Defender real-time protection and it worked. I also added the folder where the solution is saved in exclusions for Defender, and that allowed me to publish as well.
I build an executable which is dynamically linked to several DLLs. Most of these are installed by default on Windows, but maybe with slightly different versions. Others I distribute with the app, but they in turn may depend on other DLLs.
If I run the executable locally and get the Windows error message saying that "Failed to load [whatever]. The application configuration is incorrect" it seems to mean that a library that 'whatever' depends upon is missing. But it (rather infuriatingly) omits to specify exactly which DLL it was having trouble loading. Sometimes I can work this out by using Dependency Walker to see if there are any libraries that are obviously missing. Other times, I can resort to Process Monitor which can show me which file Windows was looking for prior to issuing the error message.
But these aren't tools that are reasonable for an end-user to have to use, when trying to diagnose their problem. Is there any way of coaxing Windows to say precisely which library it is having trouble resolving, so that this can be output to a log or displayed in a message box?
In my experience, a common cause of this kind of error is accidentally shipping a component that was linked against the debug version of the C runtime, which is explicitly not redistributable, and so it is only on an end user's system if they happen to have the matching version of VisualStudio installed. It will have a name that looks something like MSVCR80D.DLL instead of MSVCR80.DLL.
Dependency Walker is certainly the right tool to use to check your executable as a developer. It can hook the application for DLL load events and run it, so you can discover DLLs that are dynamically loaded at run time as well as the DLLs that were named at build time.
Dependency Walker is also scriptable, and can write a log file. I use it this way as part of my build process to validate a shipment before packaging for release. I stage all the files to be shipped into a mockup of their delivered directory tree. I use a debug mode of the application hosted by dependency walker that makes it load all its optional bits and pieces then exit. Depends.exe leaves me a nice log file, which I inspect with a Perl script and fail the build if any DLL was loaded from anywhere on the system other than \WINDOWS or the staging area, or if an unexpected version or debug version of the C runtime was loaded. Only after that check succeeds do I build the InnoSetup installer package that will be released. This has saved embarrassment on a couple of occasions and was well worth the effort it took to figure out how to do.
If you know that every DLL is either an "official" Windows DLL or part of your shipment, then you have a really good chance of it all just working on the cusomer's machine.
Edit: The official home of Dependency Walker is a good place to poke around. The version offered there may be newer than the version included with MSVS, and there is a fair amount of decent documentation on advanced uses.
I can confirm that I have run IE profiled under depends.exe, but not tested much at all.
The windows event log usually contains some valuable information after these messages.
In XP, Right click "my computer", select "manage" and go to the "Event Viewer" there, check the system log, look for error messages which appeard about the time when the message box appeared. There should be a few of them. one of them will contain the name of the offending dll.
One technique I find useful is to create an installer project in Visual Studio (even if you don't end up shipping it). Inside your solution, create a new Setup and Deployment project and add the primary output of your project to it, then build the installer. This will do a dll dependency check phase which you'll see listed in the 'Detected Dependencies' section. So if there any dlls that you have omitted you should see them in this list.
Of course, now that you have an installer that's taken only 5 minutes to set up, you could ship that and it will deal with ensuring that the Visual Studio runtimes are setup correctly too.
I've inherited a VB6 project that I'm trying to "Make".
The build fails on the "Making EXE" step with a licensing error:
License information for this component not found.
You do not have an appropriate license to use this functionality
in the design environment.
How can I figure out which component is missing the license?
The project has about 15 references; a mixture between commercial and Microsoft. I've installed development versions / licenses for all the obvious references - and checked that I can compile their sample apps successfully.
Of the remaining 13 odd references; how I can get more information as to which component is throwing the licensing error?
Any tips / techniques on how to get a more verbose error message would be greatly appreciated!
It's worth trying both the Microsoft fixes - one and two - for this error, in case you've run into one of the known issues.
If that doesn't work, open the form designer for every single form in the VB6 IDE. Look out for an error message box on displaying a form. When this error is displayed, the IDE writes a log file formname.log that gives more information on which control caused the problem.
Create a new, empty application with all the same references
Confirm that you still have the same problem
Delete the second half of the references
If you still have the same problem, then the problem is with the references which remain. Go to 3
If not, then the problem is with the references you deleted. Put them back. Delete one half of those you put back. Go to 2.
Basically, just a binary search, except it's really "binary delete".
All of the links of all of the answers are broken... And, some of us are still trying to either maintain or convert old VB6 applications (or both).
A somewhat useful tool was Process Monitor by Mark Mark Russinovich of Microsoft (it is sourced directly off of Microsoft.com and has been around for years). It allows you to monitor all resources used by the computer system wide, and allows you to filter that down to individual resources, processes, etc.
The useful bit is to start the program, and click the "Filter" button from the toolbar (Ctrl-L). From there, you need to add a rule. Select Path that begins with and that should be to the value "HKCR\Licenses". That is in the HKEY_CLASSES_ROOT section, where the Active-X components licensing information is. These should be set to Include.
Click Ok, and then click Clear on the toolbar (Ctrl-X) to clear all current events to reset the state. Events should already be populating that match that rule.
Then, invoke your build. To cut down on clutter, I used the command:
"C:\Program Files (x86)\Microsoft Visual Studio\VB98\vb6.exe" /make <project file> /outdir <exe dest dir>
Once the compile runs, the build should fail with the same message, but simply open the Process Monitor, and you can see that last key that tried to read and failed. The UUID that says not found is the UUID where the license should reside.
From there, you can:
If your license allows, copy that value from a working PC and install it into the failing PC.
Google that ID, to see if there are instructions on how to obtain the correct
license (such as install it from one of the .REG files from the installation media)
Obtain and install the license some other way
While it doesn't tell you exactly what component corresponds to that UUID, it at least lets you get the specific UUID that is failing, which is further than any of the other current answers can do in their current state.
Try This
http://support.microsoft.com/kb/194751/EN-US
It will fixed VB6.0 Design Time License