New Developer/Engineer working on a project where I can't find my "msvcr120d.i386.pdb" file from my "msvcr120d.dll". The issue arose when I prompted my application to run a specific tasking, and I don't want to load code due to the fact that it is literally scaling different classes. I really just believe that I need to get all the Microsoft Symbols so I can path them locally on my Machine. The machine is offline and can never access the Internet, but I do have a machine accessing the Internet and would like to know how to just get the files without my development machine requiring access to the Internet.
You can download them from Microsoft to install locally.
Get them from here
Related
I developed my application with Qt 5.2.1 and MinGW compiler.The installer is created with NSIS and doesnt even require admin privilege.
I use blogger as my application's website, and post Google Drive links to download the setup files.
Suddenly Drive is now showing my application as a virus, even though I checked with virustital.com and the Windows anti-virus software.
I have not received any response to the post I submitted on their forum.
So I would like to know if there is any known common cause for this problem and whether that can be resolved.
PS: I have previously used the same Google services for another software that I developed few years ago, but never ran into such issues.
This is probably false-positive alarm.
Sometimes NSIS generated installer is recognized as virus (which is wrong).
Write to the AV company (I am not sure which AV software G drive uses) and report this problem - they should whitelist your software.
Sometimes simply rebuilding the installer helps too :)
Or my last idea is to remove 'dangerous' code from installer: many times inetC and various other internet calls are suspicious.
We have an internal, isolated lab network that does not have internet access. We often run various tools on PCs on this network that require symbols corresponding to the Windows/MSVC(pp)/MFC binaries installed on these PCs. An example of one of the tools we run is the Visual Studio stand-alone profiler (ie vsperfcmd/vsperfreport/etc). Currently we can pretty easily get our company's symbols... and through some digging around our local symbol cache on the Internet exposed PCs, I can manually find symbols that correspond to binaries on the PCs in the lab network. This is a very tedious, error prone process and its pretty annoying. I'd like to find a better way to automatically look up the symbols from our lab network.
Ideally I'd like to setup some kind of symbol server on the regular network that is visible to the lab network so these tools can work correctly. Is there an accepted way to do this? Can I mirror the MS symbol server or provide some kind of proxy to the local network?
Sounds like your lab is not completely isolated, since you have machines that are connected to both regular intranet network as well as to the lab network.
In this configuration you can use SymProxy: http://msdn.microsoft.com/en-us/library/windows/hardware/ff558846(v=vs.85).aspx. You will have to install it to the dual-NIC'ed machine that is visible from lab and is able to fetch files from internet.
I know that this topic has been posted over a dozen times, but I wasn't able to find a topic that fit my issue so I will post all detail below.
To start I will mention that I have two projects: The first is the main application and the second is a DLL. The project was due for a major revision and needed a DLL to be replaced due to the company I work in switching vendors. After creating the DLL needed to import into the project I was successfully able to test and run on my machine as well as other developers machines. However once I tried to deploy it on our barebones testing machine I got the error stating that the application configuration is incorrect.
Seeing as I've seen this error before I tried to install the vcredist but I got the same error message. I tried using dependecywalker to see if I had all my needed files for the application to run to which it stated that I was missing MSVCP80.DLL, MSVCR80.DLL, and MSVCR90.DLL. Seeing as running the vcredist didn't help I tried to create a msi installer. Once I deployed that I got the application to run, but at the same time it didn't. The application needs to load in configuration files to be able to run properly otherwise it is not able to connect to our database.
I was wondering if anyone had any advice on how I can include the needed policies/dependencies in order to get this project to be able to run successfully.
To sum it up:
Release application is able to run on other developer machines and
able to load all proper configuration files, but cannot be run on any
bare bone or test machines.
Application created from Visual Studio Installer is able to run, but
ignores the configuration file directory and tries to load in default
directories.
Project is built using VS2005 C++.
Any help would be greatly appreciated.
Thanks,
Sebastian
There are different versions of redist regarding the VS service pack. So make sure, that if you have installed the VS2005 with service pack 1 you provide the redist for VS2005 service pack 1.
You might have gotten the ATL security update on your build machine but not the target.
My open source project it is C++ dynamic linking library. Most of bugs - crash.
I want create public symbol server to simplify debugging with memory dump.
See also: Setting up a Symbol Server
I assume you're using Microsoft tools? If so, all you should need to do is expose your 'symstore' directory with a web server then configure debuggers to access that store:
srv*symbol-cache-location*http://your.web.server.com/symboldir
The "Debugging Tools for Windows" docs (debugger.chm) has details for configuring IIS - I'm sure any other HTTP server will work just as well if you don't need authentication, which I imagine would be the case for an open source project. As far as I know, symsrv.dll just makes normal HTTP GET requests for symbol files when it's trying to get them from an HTTP server.
You'll also need to build the symbol store using the 'symstore' utility. Hopefully that can be integrated into your build or packaging process so it happens automatically. Again, debugger.chm has good docs on the tool.
This will not be a real answer, but you might want to take a moment to vote for C++ support in NuGet in work item Support Managed C++ Project Types or have a look at the discussion about C++ Project support. When that gets in, SymbolSource support will follow shortly (currently it only supports hosting symbols for .NET assemblies).
I am trying to get the PowerBuilder 10.5.2 sample web services application running. I can open the workspace just fine, and I can see the objects and even run the app but I get a "bad runtime function reference" error when I try to invoke the service.
I believe I have installed all the requisite parts:
PB 10.5.2
.Net 2.0 SDK
Web searches reveal that some of the web services used by the sample app are defunct, but I can't imagine all of them are, so the error seems to indicate a problem with the setup or objects, not the third party services.
I can see pbwsclient105.pbd in the workspace list and in the Sybase shared objects directory. However, as a test, I tried to use the alternative method the documentation listed for setting up the PB proxy to the .Net web service objects (by importing PB extensions from pbwsclient105.pbx) and got a "invalid dll error" so perhaps my web service libraries are corrupted?
What else could be missing? Path settings? Incorrect .Net 2.0 SDK installation?
* * * Edit: Problem Solved - at least on my machine(s) * * *
I took a cue from the thread I found here and began examining what was happening with PowerBuilder when these errors occurred -- both during the import of the PBX and during runtime if you executed the sample application.
One person in the thread mentioned the issue was related to libeay32.dll and ssleay32.dll. This is not the first time OpenSSL has given me fits with these components -- my hard drive is littered with them in various application folders. These DLLs get loaded by PB when the PBWSCLIENT105.PBX extension is imported or by an app using the associated PBD at runtime. Sure enough, by using ProcMon, I was able to confirm that libeay32.dll and ssleay32.dll were being loaded from Windows\System32 as opposed to the version of the same DLLs located in the PB folder structure. Apparently, this is a problem. I renamed the two DLLs located in System32 to effectively remove them, fired up PB and the import of PBWSCLIENT105.PBX worked like a charm.
I have a similar issue with our PB 10.5 installation. Importing the PBX file gives me the error message:
---------- Import PB Extension:
Importing C:\Program Files\Sybase\Shared\PowerBuilder\pbwsclient105.pbx - Error: The file is not a valid dll or pbx file.
---------- Finished
I initially thought the issue was that the files were corrupt, etc. However, I installed PB 10.5 on a clean machine (a VM actually) along with the .Net 2.0 SDK and the import worked flawlessly; also, I was able to call a web service. Every developer in my group has the same problem on their own machines, but if they use a "clean" machine or VM with PB installed (and perhaps a few other apps), the import of the PBX file works without issue.
At this point I am trying to pin down what in the environment causes the problem, but haven't been able to yet. What's interesting, as you've noted, is that if you open the sample application, you can see the exact same imported libraries present; however, you get the error at runtime. All of this really points to something environmentally missing or incorrectly registered. So, if you have the ability to use a VM, I recommend that as a temporary work around.
One thing I'll add here: if you happen to use Vista or Windows 7 as your VM, the import of the library works fine, but I had issues generating the client-side proxy using the .Net web service engine. I finally discovered that in the background, the SDK tool WSDL.exe is being executed against the WSDL for the service in order to produce a .Net client-side proxy. Turns out that Vista/Win7 User Access Control was preventing WSDL.EXE from running. I ran PowerBuilder "as Administrator" and everything worked as expected in terms of generating the client-side proxy.
If you discover anything about why the PBX import doesn't work, I'd be interested in hearing about it!