I've just discovered that regtlib.exe appears to be missing from Windows 7 (and apparently from Vista as well).
I've just installed Windows 7 RC in a VM and I'm attempting to build our existing projects on the new OS. The projects are c/c++ based and I'm using visual studio 2008. In order to build these projects I need to register several tlb files that are referenced within the code base.
Has anyone also encountered this problem? And, has anyone managed to solve this?
Thanks.
Yeah regtlib was removed from vista and up. As far as I know, all it does is call LoadTypeLibEx with the REGKIND_REGISTER flag (http://msdn.microsoft.com/en-us/library/ms221249.aspx). Maybe you could write a simple replacement.
Just came across this issue (couldn't add any components to a VB6 project on Win7). This post (Error accessing the system registry in VB 6 IDE) pointed to regtlib (which is missing from Win7). I just
set the VB6 start menu icon to 'Run As Administrator' and it worked fine for adding components and should fix any problems relating to updating the registry as well.
Regards
Ian
Finally got back to trying to build our code base on windows 7. Anyway, I went back to the installer for one of the dependencies that was causing me grief. The error message from the installer wasn't to helpful but it did point to a regasm that was being run from inside the installer.
I ran the regasm command from a cmd prompt and got more information. It appears that you need administrative credentials to perform this task and our current installers don't do the privilege escalation properly.
So, long story short, I got dlls registered and the build appears to be working.
Related
I'm new to Qt, but have been working with Visual studio for C/C++ development for a few years. Now I'm trying to build a GUI for my project. I installed Qt 5.11.0 and the Qt VS Tools on both my work computer and home PC. At work I can build and run my project with the VS debugger, however on my home system I can build but can't run either with VS debugger or simply launching the app. I tried in release and it runs fine.
The error I'm getting is :
The code execution cannot proceed because VCRUNTIME140D_APP.dll was not found.
I get 4 of these, the first two want VCRUNTIME, the second two want MSVCP140D_APP.dll.
Solutions I've tried so far :
Uninstalled Win SDK and reinstalled
Uninstalled VS2017 and SDK and reinstalled
Searched System32, SysWOW64 and VS install directories - found msvcp140d.dll and vcruntime140d.dll, but no _app.dlls
Does anyone know what these are included with and where to get them? I can't figure out why I have them on my work computer but not at home. I have the same VS updates, same Qt version, and SDK on both systems.
Using :
Visual Studio 2017 v15.7.1
Qt 5.11.0 - msvc2017_64
I suppose I can just copy the .dll's from my work pc and drop them in the appropriate locations on the other, but I'd like to know what they should have been installed with so I can have the same setup on both systems.
Edit:
I also tried changing the platform toolset to VS2015 with Qt versions msvc2015_64 and winrt_x64_msvc2015
I found this post concerning the same missing _app.dll files. There wasn't any answer there, which is why I tried reinstalling the SDK in the hope the missing files were included there.
Edit 2:
I just scanned my entire system at work and it turns out that I don't have the missing .dll there either. That tells me that there is a difference in the project properties or configuration between the two. I use git for source control, and I am currently the only contributor to this project. When I try to build and run just the example from the getting started guide I have the same problem at home with missing _app.dll files, however it works fine at work. I'm totally confused now, and any hints are greatly appreciated.
Solution:
After trying for a couple of hours making new solutions etc. I decided to delete the entire build folder and put fresh copies of all the dependencies into it. My project now runs fine in debugging mode.
I'm fairly certain that when I originally copied the Qt .dll files into it I must have grabbed them from one of the winrt folders rather than the msvc2017_64 folder. To test I replaced the working .dll files with those from the winrt_x64_msvc2017 folder and sure enough the same errors again. So, this was a dumb mistake on my part, but hopefully it'll save someone else a lot of hair-pulling in the future.
I've looked for an answer during a few days and I haven't found anything similar anywhere;
I downloaded Qt from the official website, installed it and apparently compiling is fine. But whenever I try to execute (Ctrl+R) any app, even the basic one which only displays a window or widget, QtCreator itself crashes. No error message, nothing, just crashing.
I've tried to redownload and reinstall it a few times with different settings, but nothing will do.
I'm running QtCreator on Windows 7 64 bits. I'll try on my laptop which is also running windows and will update if I find anything.
Any help would be appreciated, I need to start a project as soon as possible. I'm relatively new to QT and if you need info on anything just ask me. Thanks :)
Use dependency walker, http://www.dependencywalker.com/
and post any missing dependencies. It is possible some install targets or options are missing from when you installed QtCreator, which can be resolved with the maintenance tool in the same directory you installed Qt.
Also, are you using the Visual Studio compiler(must have Visual Studio installed separately, and mark the option during install), or the Ming compiler(2 options checked during install or maintenance)?
Check if your antivirus is locking it, I had a similar issue time ago and it was due to antivirus (Avast specifically). Disable antivirus' realtime shields and try to execute a basic app.
It is necessary to use QtCreator? I use QtDesigner snd VS2013 and things go very well. :)
check this thread Qt Creator Plain C++ Project won't run/debug... and this C++ - QtCreator doesn't show any output
here is some information to understand my situation better.
OS: windows 8.1
IDE: Visual Studio 2008 Pro
Language: C++
i have just my Firefox reinstalled and after this(maybe it was not the reason),
my visual studio Project compiled only with 9.0.30729.6161 VC++ Runtime DLL.
Until yesterday it always compiled with 9.0.30729.8387 VC++ Runtime DLL.
Because of this (or maybe other reason), now i cannot start my Project.exe.
Nothing is changed in source-code. Project-Property and all other things are also unchanged.
I just get the error number 0xc000007b suddenly.
How can i fix this?
It was because of an 32bit DLL, which should not be loaded for my 64bit Project.exe.
I have found this with Process Monitor.
I don't know why, but anyway is the "path" is changed and the 32bit DLL(which has the same name with 64bit DLL) is loaded..
If you have the same Problem, check whether there is a problem between your application and its dependencies using dependency walker.
Entered the answer in another place, but figure it could be helpful for folks who badly need some help:
It has been mentioned in other answers that using dependency walker is the way to go, in my case (my application keeps failing with the error code), dependency walker showed a few dll that are NOT relevant!
Finally figured out that I can run profiling by going to "profile" menu and it will run the application and stop at the exact dll that's cause the problem! I found out a 32bit dll was picked because of path and fixed it.
-Turn off your antivirus software before starting the installation.
-Accept any additional software offered during installation process, since it may be crucial for running your application properly. You can skip things such as search bars, antivirus scanners, registry cleaners and the other software which isn’t directly related to the application.
-Install an application to the system partition (C:). Although this shouldn’t matter, it’s been proven that some apps may return an error if installed on a logical partition.
There is more than one way to solve it. This link might also be helpful.
http://finally-found-the-solution.blogspot.com/2015/02/how-to-fix-0xc000007b-application-error.html
Well, I am facing a strange problem. I have developed a sample MFC ribbon application on my machine - Windows 7 , with Visual Studio 2008. When I copy paste the .exe onto my laptop and run the app , I don't see the ribbon menu (in fact the app has not menu now) .
I have tried looking up the .dll that load in each case(on my work machine and laptop) using process monitor but I am unable to locate what I might be missing. Any help will be greatly appreciated.
Edit 1 -
Ok, So thanks for your responses. Some progress has been made with this issue
I changed my IDE to VS 2010. The ribbon was coded manually and I figured out if I could add it as a resource maybe the problem would be solved. VS 2008 did not have the option of adding a ribbon as a resource.
I installed the VS 2010 Service Pack Redistributable X86/X64 depending on whether the machine is 32 or 64 bit.
I built a new "ribbontest.exe" app from VS 2010 and deployed it on other machines on which I would test my actual app. The ribbon for "ribbontest.exe" loads without any problems.
When I deploy my app and run it, first the old menubar loads for a sec or two, then the ribbon flashes and disappears.
A little history of the app I am referring to -
Initially my application had the menubar view. I followed this article http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm to accommodate a ribbon.
Any suggestions?
Most likely there's a conflict in the settings 'paths'. In your InitInstance() handler, you've got a statement like this:
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need
// Change the registry key under which our settings are stored
SetRegistryKey(_T("yourappname"));
If you haven't changed that name yet, do it. If you did, open regedit.exe on your target machine and remove the whole key under HKCU\Software\yourappname and then try again.
MFC stores user customizations of Ribbons/Menus/... under that key. But if you changed your app those settings don't necessarily match anymore and you can end up with stuff not showing correctly or not at all.
Make sure you download and install the Visual C++ Redistributable Runtime on your destination machine: http://www.microsoft.com/en-us/download/details.aspx?id=29
Or, something like it. Make sure you have architecture (x86/x64) correct and make sure it matches with the service pack version you compile with.
Joe is right: you need redistributable.
Joe is right: you cannot run 64-bit program on 32-bit machine.
All of the above would be indicated by the system (missing DLL, configuration incorrect, or 64/32 bit discrepancy)
Joe is right: your application must be built for specific set of minimum Windows version and service pack.
In addition to Joe’s post you must run release build not debug build.
If all of those requirements are met and you still have this problem, try linking MFC statically and see if problem persists.
I'm using WMI's CreateProcess() to run an installation bootstrapper process (setup.exe) on a remote machine. The setup.exe is happily able to run .msi packages but for some reason it is not able to run the vcredist.exe packages that are used to redistribute the MS VS 2008 SP1 C++ Runtimes.
What I'm seeing is that the redist package is able to extract itself into a temp folder in the root of the C:\ drive, e.g. C:\a26f91763649ecad76a09d or some such, but after that the process hangs around.
I don't know what to do to debug further - I suspect that there is a modal dialog in the hidden windows station awaiting dismissal, but I can't see what the text is. Process Explorer isn't yielding much either.
Anyone got any suggestion? The problem applies equally in Windows 2000 as in Windows 2008. We used to use a DCOM-based method to launch setup.exe remotely and this did not exhibit the problem.
Can anyone shed any light on what might be going on, or how to diagnose further.
Many thanks,
Stephen
User error! My suspicion about the modal dialog was correct. It seems that invoking the setup.exe files with a relative path somehow caused the command line arguments to get stripped when passed to the nested exe, so they ran in full UI mode! Invoking with a fully-qualified path resolved the problem.