I am working on a program which I suspect to have one or more memory leaks. Some other answer on Stack Overflow told me to try DevPartner BoundsChecker (one of many others I tried).
Now when I run my program with BoundsChecker running, it will break. At some point, a Windows file open dialog will get initiated and right before that actually happens, a non-continuable breakpoint gets triggered. This only happens with BoundsChecker running.
According to the Console Output, the last thing that the program is trying to do is to load C:\Windows\SysWOW64\slc.dll which DevPartner recognizes as the "Microsoft Software Licensing Client Dll". Since we do not use any software licensing in that particular program, this must somehow be related to the dialog window that is supposed to be opened.
Anyway, I really want to find those memory leaks and for that, I need to open that file. Is there a possibility to tell BoundsChecker not to break my program because of this issue (whatever that issue might be)?
Basti, there was known bug in the 9.x versions of BoundsChecker with the MFC file open prompt. If you post your DPS and Visual Studio versions I might be able to tell you which patch or update you need to get around this. On the other hand if you really are tripping up in a licensing guard DLL, BoundsChecker may be exciting some anti-tamper logic in it. I have seen DPS raise the anti-tamper logic in other Micro Focus products. If it is the latter you would need to raise a case with Micro Focus customer care and provide a repro test sample. Shameless plug: I work on the DevPartner team. We are releasing DPS 10.5 with BoundsChecker for x64 application support on February 4, 2011. Please see if this version corrects your issue once the download eval is posted.
Related
I notice that Microsoft Visual C++ runtime libraries are duplicated all over my computer, eg: at the following locations:
C:\Windows\System32
C:\Windows\SysWOW64
C:\Program Files\Common Files\microsoft shared
C:\Program Files (x86)\Mozilla Firefox
C:\Windows\WinSxS\amd64_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_b157f27efd203c73
C:\Windows\WinSxS\x86_microsoft-windows-u..lcrt-apifwd-winblue_31bf3856ad364e35_6.3.9600.18036_none_553956fb44c2cb3d
Why is this? I thought a specific .dll could only be registered ONCE with windows? Is that not the case? Can you really register the same .dll from multiple locations?
I uninstalled an old version of Skype which had the C++ .dll's in its own folder. But doing so caused a whole load of other programs to break (eg Adobe Acrobat, etc). I fixed it by repairing the C++ 2015 redistributable from Control Panel's Programs & Features window. But while checking the damaged files were re-created and re-registered, I discovered so many versions. How do I know which one is registered with Windows?
If I wanted to write code that referenced those .dll's, which one would it use?
I found a hint of reason for this in this article.
Consider this scenario: you install program “A” and it uses library
version 1. You then install program “B” and it also uses library
version 1, so it doesn’t need to install it – it can just use the copy
that’s already there courtesy of program “A”. Now you uninstall
program “A”. Three things can happen:
It uninstalls the library because it installed it and it should clean
up after itself, not realizing that another program relies on the library. Program “B” breaks as a result.
It never uninstalls the library because another program might be using it. As a result, libraries check in, but they never leave.
We devise some method of tracking how many installed programs are using the library, and only remove it when the last one is uninstalled. Unfortunately, any single program’s failure – be it a programming error or a failure to install or uninstall properly – breaks this technique. At best, you’re left with copies of the library you no longer need, and at worst, uninstalling one program can cause one or more other unrelated
programs to fail.
It’s a mess. In fact, it’s such a mess that most
programs now don’t bother to try and share at all.
Putting Your Fate in Someone Else’s Hands:
Ultimately, application vendors realized that by relying on shared libraries like this, they were putting their fate into the hands of every other application that happened to use the same version of the same library. If only one of them made a mistake, and the library was accidentally removed or updated when it shouldn’t have been, it put all the others at risk.
So, application vendors typically now install their own copy of the
library that they manage and that they can rely on. Disk space is
cheap – much cheaper than the errors and frustration that were
happening when they tried to share.
So now, on my machine, many different applications all carry with them their own copy of the Microsoft Visual C++ Runtime.
And each is more stable as a result, by virtue of being in control of
their own destiny.
However, it remains unclear how dll files can be registered with the same name but from different locations. I did not think this was possible, but perhaps it is.
I have a problem in my program. The program is Magic Xpa 3.3. Every I run the program with click program icon or with "run as administrator", I have error 0xc00007b. i have been try to fixing an error, I re-instal the program, I re-install Microsoft Visual C++, I update .Net Framework, I run chkdsk, but still error 0xc00007b.
Do you have other solutions to fixing an error ?
Hmmm, it's not that simple because you have to provide more info.
Please note that xpa is not a "program" - it's a framework for developing and running software solutions. Xpa comes in two flavors: toolkit (development) and run-time.
If you have an issue with toolkit, which i doubt, make sure that you have IIS installed.
In case of xpa run-time, you probably have application developed in xpa and set to run in xpa run-time. Most likely you have to ask for person who made that application. There are many issues related to setup of application (database access, path to application, licence info etc.) and it's almost impossible to say what exactly is wrong.
I agree with Sami Kuhmonen: this question is not a programming question because it's clear that you are not Magic/xpa developer. You could try to get more help at https://magicu-l.groups.io/g/main
I'm installing Visual C++ Redistributable 2013 as a prerequisite (if its not installed)through my installer. But sometimes already installed VC++ is corrupted then my installer does not work because I'm having DLL functions called in CustomAction.
So my question : Is there any way to find whether the installed VC++ redistributables is corrupted or not ?
Health checks in general are a pretty difficult topic. For files built into Windows, there are tools like SFC, but that doesn't extend to other installed packages. For MSI packages, you can choose to run repair, and in some cases Windows will do this automatically; this topic in general is called Resiliency. But unless auto- or manual-repair fixes the sorts of problems you encounter in the wild, it's not very relevant.
So the question becomes what sorts of problems do you actually encounter, with what frequency, what their fix is, and what problems can be caused by attempting to fix them. If it's sufficient to invoke a manual repair of the VC++ redist, that's fairly easy to implement. If a full uninstall and reinstall is required, that's much more invasive; the idea of making that part of an installation rubs me the wrong way. If you have to do this only in very specific situations, it may depend on how well you can identify those situations.
Alternately, if your focus is ensuring that your installation succeeds, you may be able to statically link your custom action DLLs so that they no longer depend on the state of the VC++ package. This will not help your application much if the application also depends on the VC++ package, however. Perhaps a privatized copy of the VC++ DLLs can address that (if the 2013 version supports that--I forget), at the cost of more difficulties servicing your copy of the VC++ DLLs in case of security updates.
But again, this all depends on what sorts of problems occur, whether they're frequent enough to merit addressing them, and whether the cure is worse than the disease.
It seems that LLDB plugin for Eclipse is still not developed yet, but this article claims that one can debug a program with LLDB-MI driver in Linux. However described way of integrating Eclipse and LLDB doesn't work for me (I always get "command --exec-continue not recognized" error message) and it looks suspicious that embedding LLDB-MI to Eclipse may be so easy.
Could anyone point me to curren materials on this topic? Google shows me only old Eclipse-bug-tracking threads.
There is a project called lldbmi2 that provides most of the functionality one would need. I know it's been developed primarily for the Mac and I don't know if it's been tested on Linux. It's not perfect, but I've been using it on the Mac for months and I'm pleased with its functionality.
See https://github.com/freedib/lldbmi2
When an MFC application starts, is it possible to check for the Visual C++ runtime before the "application configuration" error is displayed?
I assume it must be done via pure Win32 API at some point before the CRT loads.
The error is coming from the operating system, before your program is even finished loading. There is no part of the program, not even initialization, which has run yet. Thus no way your program can eliminate the error message by itself.
Edit: You might be able to set the runtime DLL as a delay-loaded DLL to get your program loaded in the absence of the runtime. Then you'd have to substitute your own function for the .exe entry point and have it check for the existence of the runtime library. There are many technical difficulties associated with this approach, and I'm not even sure it would work at all - but it might be possible.
Well, you get that error because you're missing the redistributables. So instead of trying something like that, you should rather install the VC++ redistributables from Microsoft (as prerequisite for your application). I used to keep a list of the downloads here.