I am encountering a strange problem.
1>I open visual studio 2012
2> I open matlab 2014a (32 bit)
3> I try "Attach to process" and put the matlab process from the list displayed in the process window that comes up.
What happens is I get window in visual studio saying
"Loading symbols for tbb.dll from:
z:\itt\branch_tbb40\tbb\1.0\build\fxeowin18vc10_32_release
Attempting to cancel will disable furhter symbol loading"
and hangs.
The issue is "z:\itt\branch_tbb40\tbb\1.0\build\fxeowin18vc10_32_release" does not exist in my computer. How come visual studio is trying to load from this folder ? where is it getting its information from.
Also the tbb.dll is in the "C:\Program Files (x86)\MATLAB\R2014a\bin\win32" folder which I have put in the path environment variable.
How come visual studio is not looking there.
It would be very kind if someone gives my some pointer to fix the issue.
Thanks in advance.
z:\itt\... is the path where the pdb was when the dll was originally built from source, possibly on a build server or so but definitely not on your machine so it's normal you don't have that directory.
When loading symbols for a dll, the debugger will also look for the original pdb path (which is stored in the dll) apart from considering various other paths. As far as I know the PATH is not used when looking for pdbs so don't bother adding directories to it for that reason. The directory where the dll is located is searched, but you probably don't notice because it flashes by quickly in VS. (note if you want to see all places where VS searches you could use procmon).
As to why VS hangs: no idea. But does it really hang 'forever' (as in not responding + corresponding dialog)? One possibility would be that z: is mapped as a network drive and VS is waiting for a response from it, which should timeout after a while.
Related
I have an Excel workbook that calls a test DLL I wrote in C++. The path to DLL is hardcoded in VBA. The only files the DLL uses are stdlib and iostream.
On my machine it works. On several other office machines it works. However, on the remainder when i try to call the DLL through Excel I get error 48 - file not found.
My understanding is error 53 is the file is missing; error 48 is there are missing dependencies. I have used dependency walker and have not found any issues.
What I did discover, however, is that if I install Visual Studio on a machine there is a 90% chance that after the install the Excel file/DLL works perfectly. On the 10% that it does not work, I restart and re-run the Visual Studio install, selected 'repair', and after the installation finishes again the Excel/DLL combo works. So basically installing Visual Studio allows the DLL to be loaded by Excel. If i uninstall Visual Studio the DLL still works fine.
Obviously this means something is missing on those machines, but I have no idea what - I've tried separately installing all the pieces that show up under 'programs', such as most current .net framework, visual c++ re-distributables, etc... and it doesn't work. The only thing that works is installing Visual Studio itself.
I'm not certain how to proceed since asking users to mount a 5gig ISO and install a developer environment isn't really ideal.
Ah-ha, I found the issue. It turns out that it requires 2 DLL files - msvcr120.dll and msvc120.dll. I had these 2 files in my System32 folder, but not in my SysWOW64 folder. As soon as i populated that folder then the DLLs started working.
I found many threads on google with the 'same' problem but no answer, so if you run into the same issue I'd suggest using dependency walker and making sure the DLLs are in both system folders to be safe (although I suspect System32 is only needed for 64bit DLL, and SysWOW64 for 32bit DLLs).
Most probably your DLL depends on C++ redistributables. Depending on the version of VC++ you have used to develop your DLL, you should install the relevant version of VC++ redistributables on the target machine.
In case of VS 2015 you can find VC++ redistributables here:
https://www.microsoft.com/en-us/download/details.aspx?id=48145
Use the SysInternals Process Monitor utility to monitor DLL access and look for errors. An example is in this other answer. Watch the Excel process and the CreateFile operation.
Ah-ha, I found the issue. It turns out that it requires 2 DLL files - msvcr120.dll and msvc120.dll. I had these 2 files in my System32 folder, but not in my SysWOW64 folder. As soon as i populated that folder then the DLLs started working.
I found many threads on google with the 'same' problem but no answer, so if you run into the same issue I'd suggest using dependency walker and making sure the DLLs are in both system folders to be safe (although I suspect System32 is only needed for 64bit DLL, and SysWOW64 for 32bit DLLs).
Error 48 can also be returned when the dll does not correspond to the bitness of the calling program. So, if you're runnning Excel's VBA with Excel 64-bit, for example, you want to make sure the DLL is compiled as a 64-bit binary.
Note this is different from error 53 wich really means the DLL is not found in any paths.
I am trying to debug my C++ program in Microsoft Visual Studio 2010- having just recompiled the code after making some changes, have run the program, and am now trying to attach to the process (Debug -> Attach To Process...).
However, when I do this, I am presented with an error that I've never seen before:
'AMSCDNUSimulatord.exe': Loaded 'C:\Program Files (x86)\McAfee\Host Intrusion Prevention\HcApi.dll', Cannot find or open the PDB file
The thread 'Win32 Thread' (0x1c04) has exited with code 0 (0x0).
I haven't done anything differently to what I normally do (built the project, copied the 'AMSCDNUSimulatord.exe' (debug executable for my program) from the workspace to the release folder of the program- overwriting the existing .exe file), run the program, and attached to process from Visual Studio's Debug menu.
This usually works with no problems at all- but for some reason, I'm now getting the above error in Visual Studio's console... Anyone know anything about this?
I haven't changed any configuration of McAfee or anything, so can't think why it would be complaining about that.
I have tried checking the "Microsoft Symbol Servers under Symbol Locations" as suggested in answer to: Visual Studio 2010 "Cannot find or open the PDB file", but this doesn't seem to have made any difference.
With regard to the set up of my project, the source is in the folder C:\Workspace\Simulator, and that is where the .exe file is placed when the project is built. I am then running the release from C:\workspace\release\Simulator, so I copy the .exe from the first folder to the second once it's built, and run it from there. The thing is, that I've been following that method exactly for months, and never had any problems running the program and attaching to the process before, so I doubt that the issue is anything to do with the change to that I've made to the code... but how/ why would McAfee now be preventing me from attaching to the process?
My C++ code in Visual Studio Express 2013 (code replicated from a programming book I was using) generates a whole bunch of errors too long to list here... But each error is the same problem:
"Cannot find or open the PDB file."
An example of one file it was trying to find/open is: C:\Windows\SysWOW64\KernelBase.dll
Anyone got any suggestions? I'm a total newbie so please use plain words!
Cheers.
When you build a binary with VS, VS creates a program database for it. When debugging a process, VS searches for debug symbols next to the binary.
As long as you don't need these symbols (to set a breakpoint in e.g. WaitForSingleObject or so), you don't need the .pdb either.
However, when the debugger tries to construct a call stack, it often does need the symbols (it will tell you that 'frames might not be correct'). In that case, you can tell VS to retrieve the microsoft program databases from the Microsoft Symbol Servers.
Note: when all this symbol-loading slows down your process, there are settings to disable automatically loading them.
I'm trying to setup source indexing using Visual Studio 2010, and the included perl scripts from the Windows SDK (in my case, Windows 8) using Perforce as the source control
For Windows 8 SDk
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\srcsrv
From Bruce Dawsons blog (linked below), it may be located here for older sdks
C:\Program Files\Debugging Tools for Windows (x64)\srcsrv
My pdb's are getting indexed, and manually looking at the pdbs, as well as running the following command will extract the source files correctly.
srctool -x test.pdb
This may be a misunderstanding of how this is tied into Visual Studio, but my problem is related to local edits to files.
If I delete a file and start the debugger
VS will pop up a dialog asking me to confirm that I want to run the command and will properly download and open the source file and I can continue debugging
If I edit or sync a different version of a file so it doesn't match the pdb
I don't get this dialog, and as a result, VS displays the "No Source Available" window
From the MSDN site (also linked below):
When there is no source code on the local machine or the PDB file does not match the source code, you can use Source Server to help debug an application
It seems that this second case, should cause VS to run the command to get the source, but it doesn't seem to be working for me. Case #1 is working how I'd expect, but I need to get case #2 working before this is useful. Also, I've enabled the "Print source server diagnostics to the Output window" and I don't get any errors or warnings.
Should this second case trigger a download of the version of the source file when the pdb was indexed? Or am I misunderstanding something?
Thanks!
edit
This works as I expect in windbg, so this seems to be specific to Visual Studio
References:
http://www.altdevblogaday.com/2011/11/08/source-indexing-is-underused-awesomeness/
http://msdn.microsoft.com/en-us/library/vstudio/ms242029(v=vs.100).aspx
Thank you for identifying this issue. We have fixed the problem, and the change will be reflected in future releases of Visual Studio (not in updates to 2013). We hope this fix improves your experience with our tools and technologies.
Specifically we have modified the behavior of the debugger to match what WinDbg does in this case. We will allow you to download the matching source file from the source server if the temporary file on disk doesn't match with what you are debugging.
I have done a big project with Qt5 and visual Studio 2010. Everything is well inside of visual studio using the run button.
But my goal is of course to release it to other persons, without visual studio.
My problem is: I can't get the .exe run outside of visual studio. I was asked for several dll's at first, I found them all in the Qt5 bin folder.
But know I got rid of those messages, when I wan't to open my exe, nothing happens.
Just nothing.....
I cannot even find my exe in the windows task manager.
Does someone here know an answer to that issue?
There are dll files that are loaded during runtime and don't give you any error, warning or whatsoever when not present (also totally transparent to dependency walker). Such is the platforms\qwindows.dll - note that it must be in a platforms\ subfolder relative to the executable. You might also be missing libEGL.dll and libGLESv2.dll.
Dependency Walker is not very useful in this case as it shows very strange dll files missing: API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL etc.
You can use Qt5.x cmd prompt ( 5.x is the version that you are using) and run windeployqt.exe from your build directory. It will automatically find and copy all necessary dll files to your output directory.