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.
Related
Sorry if this is a duplicate -- I've looked at this and this and others, but I can't find my problem.
A program I build debugs successfully on my local machine, but when I try to debug it remotely, I can't set breakpoints in my code. I've opened the modules window in the debugger, and under Symbol Status for my executable, it tells me "Cannot find or open the PDB file." I try to load it manually, and get the error, "A matching symbol file was not found in this folder."
I created a minimal (hello world) app, and I can debug that, so I'm able to reach the remote PC. Indeed, the app does start up and run on the remote system. So, it isn't an access issue.
Not sure what else to say about this, other than to show you my project debugging configuration:
Any ideas are MOST welcome. Thanks...
Well, I found the answer -- I needed to check the "deploy" box in the Configuration Manager window. This surprised me a little, as using the "deploy" command (available from right-clicking the project property) didn't do the trick. Evidently, there's some behind-the-scenes magic that takes place when the deploy box is checked.
Hi all I have an software running on a machine where it was developed. Now i make a setup.exe and try to install it on other machine.
It was successfully installed without any error. All the function are running properly i.e. adding the records in the database fetching it in the dropdown but the problem occurred when I generate the report.
As soon as I click on to generate the report the error message comes saying that
Run time error'20532'
Cannot find Database DLL.
I have no idea why this is occurring it is running perfectly on the first system but why on the other system it is showing error.
I am using MS Access 97 as a database.
I check the dll's if there is some thing missing but not find anything. all the dlls are present in the system32 folder.
Now what can I do... any one have any idea please help me...
Thanks.
The error is due to the crystal reports.
I just install the crystal report on the target machine and its done.
I have created a small desktop application using .NET 4 for generating an authentication string. It runs fine on my Windows 7 computer, however when I deployed it to our QA guy on his Vista machine, it gave him an error saying he needed to install .NET 4... FAIR ENOUGH. We installed .NET 4, however the next error said that "Microsoft.Web.Infrastructure.dll" was missing from the GAC. Crap. So I poked around a bit and found this:
I then set Publish Status of Microsoft.Web.Infrastructure.dll to Include and published again. This time it gave him an error about "System.Web.Mvc"! So I knew I was on to something. So I went and did this:
However, now when he runs it it just says it can't download files required to run the application, and will not specify what they are!
How can I properly publish my Windows desktop application in such a way that will ensure the end user has the right files needed to run it?
Note: I think Razor and MVC are included because this windows desktop app project is dependent on some other projects in this solution that are using MVC. (Basically this desktop app is using some of the Models.)
Edit: Here is the end result (README was added by me not VS)
As it turned out, the second screen shot view with everything set to Include was the proper way and worked fine while the first screen shot caused missing DLL errors during install. It really was just an FTP upload user error that had the installer looking for a folder that was not there, which is why the second version did not work the first time.
I think you should be looking in the Prerequisites dialog from the Publish tab of the project Properties window, not the Application Files dialog. Not sure if this is an SP1 feature or not (I have SP1).
Image reply from Ryan (question poster):
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.
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.