My setup is as follows:
A 32 bit .net 4.0 website running on 64bit Windows 2003 server
I have Debug Diagnostic 1.2 setup to monitor crashes
I haven't got an automated dump yet but trying to analyze a manual dump.
I have a 32bit windows 7 machine which has Visual Studio 2010 installed on it which i am trying to use to analyze these dump files.
I have tried numerous ways to open the dump file it generates but all fails.
Following is what I have tried:
1. DebugDiag Win 2003
Try to use Analysis tab through Debug Diagnostic directly on the win 2003 server where the website is hosted. I get the following error
.NET runtime was loaded in the progress but managed analysis was not done on this dump file because the managed debugger extension commands failed to execue with the below error
CLRDLL: CLRDLL load disabled
CLRDLL: Unable to find mscordacwks_AMD64_AMD64_4.0.30319.1022.sll by mscorwks search
CLRDLL: Unable to find mscordacwks_AMD64_AMD64_4.0.30319.1022.sll on the path
CLRDLL: ERROR: Unable to find mscordacwks_AMD64_AMD64_4.0.30319.1022.dll , win32 error 0n2
2. DebugDiag Win 7
Try to analyze the dump on a 32bit windows 7 machine, I get the following error:
DebugDiag Analysis cannot be performed against a 64-but dump file from a 32-bit analysis machine
3. WinDbg on Win 7 x86
Try to open the dump through WinDbg tool on a 32bit widows 7 machine:
0:000> !clrstack
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks___.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
Try run the following commands on WinDBG to register mscordwks and switch to 32 bit version but still no go:
![enter image description here][2]
.loadby sos mscorkks
.load wow64exts
!sw
.cordll -ve -u -l
4. Visual Studio 2010
Try to use Visual Studio 2010 to debug this dump file but that also fails saying unable to display manged code or something.
I've spent 10 days on this already and feeling very disappointed & helpless.
Anybody who could shed some light on whats wrong here please?
Many thanks in advance.
First of all, you have a 64 bit dump. We can see this, because DebugDiag tries to load the 64 bit version of mscordacwks. Next you say that you have a 32 bit web application. This is already a bad situation for .NET. You will not be able to analyze the dump. Maybe you have taken the dump with Task Manager, which by default will generate this sort of dump.
To verify that this is really the case, run the following command in WinDbg:
lm m wow64
If this lists the Wow64 module, then it`s the bad situation. If this does not produce any output, you have a 64 bit dump of a 64 bit application, which is a much better situation. However, you need a 64 bit version of WinDbg to analyze it, otherwise you'll not be able to load the 64 bit SOS extension. Also you need a 64 bit version of DebugDiag to analyze it (see your error messages).
WinDbg should download the correct version of SOS and mscordacwks if you type !analyze -v. Also DebugDiag will try to download it. If that does not work, get the necessary files from the original machine, e.g. using Mscordacwkscollector.
Some other notes:
Meanwhile there is DebugDiag 2.1, which meíght produce better results.
Be sure to type the commands correctly: .loadby sos mscorkks does not work. It is .loadby sos mscorwks and even .loadby sos clr for .NET 4
You have uploaded a picture but removed the corresponding link. Maybe you want to edit your post and upload the picture again. Use the preview to see whether it`s there.
Related
I am using Visual Studio, Test Complete and C#. I am basing it off another project which also uses the same. This other project uses Oracle to query and works fine.
I based all my settings on the other project (any CPU, all the same references, etc). However, when I run it and attempt to connect to oracle I get an exception about a bad image (this happens when you run 64 bit and try to load a 32-bit client). I copied all the references, and tried all combinations of build. I do think I am running 64-bit because when I am debugging and try to insert a line it says it is disallowed in 64-bit mode. On the other application it lets me insert lines during debugging.
Here is the exception:
e {"Attempt to load Oracle client libraries threw BadImageFormatException. This problem will occur when running in 64 bit mode with the 32 bit Oracle client components installed."} System.Exception {System.InvalidOperationException}
I try replacing the oracle library but it always seems to go back. Better would be to run in 32-bit mode. As you can see from the picture, for some reason "Prefer 32-bit" is disabled (also in the application that works).
Any idea what to do? This will also, once it runs on my machine, be transferred to another.
This is Visual Studio 2012 (11.061219.00)
Use connection.GetType().Assembly.Location to check which DLL is actually loaded.
Typically (and simplified, see How the Runtime Locates Assemblies) assemblies are loaded from GAC (Global Assembly Cache) or from directory where your .exe is stored. Note, the GAC takes precedence!
If a .exe or .dll file is x86 or x64, you can check with sigcheck tool.
In Oracle Client 12.1 Setup and later the ODP.NET is not added to GAC anymore, you need to add it manually.
You may use my Oracle Connection Tester which could show you the problem of your installation.
I have created a project with CMake, which I now tried to profile using the trial version of Intel VTune together with Visual Studio 15. I set the Windows debug symbol server in Visual Studio, but VTune is unable to find all the symbols. My project is configured for debugging ofcourse.
1) I can copy the QT .pdb files to the project folder to resolve their location, but adding the QT bin directory to the list of symbol locations as in the picture above doesn't help.
2) It still doesn't find some of the Windows debugging symbols and therefore alot of the function calls don't show a proper name. I've also tried to manually run 'symchk.exe', but it says "FAILED - ... mismatched or not found" for all of the files in the system32 folder.
I had all of this working before, but now I formatted my computer and can't get it to work again. Any help appreciated!
EDIT: I also started to realize that there is no callstack information available. I downloaded the Windows symbols manually now as well, which still didn't help. I'm starting to wonder if it's really the missing symbols though...
Thanks for your comment. I'm using Intel VTune Amplifier 2017 Update 2 (build 499904). Someone on the Intel forums told me that my Windows version (build 15063) is currently not supported, but will be after the upcoming update 3. He sent me an updated driver, so now everything works as expected!
I am attempting to use the Visual Studio Performance Profiler to profile a process I have running. I am using the "Sampling" collection type, and am attaching to the process after it has already started. When I finish profiling and attempt to load the report, it displays the message "No Call Tree Data Is Available" above the CPU usage graph.
In addition, the following error is generated:
DA0002: It appears that the file was collected without properly
setting the environment variables with VSPerfCLREnv.cmd. Symbols for
managed binaries may not resolve.
The only information I can find on this error is around running the profiler from the command line, not from Visual Studio.
My best guess is that this may be a 32-bit vs. 64-bit issue, as I just recently received an upgraded computer with the 64-bit of Windows 7. Everything worked fine on my previous machine which had the 32-bit version of Windows 7.
I am working on a plug-in for an application. I have old development tools that have problems. My development tools are all from old 32 bit versions. CodeWarrior 6.7.and 8. I am running windows 7 pro 64 bit and having problems with the old tools. The CodeWarrior debugger will only work one time and I have to reboot before it will work again. It also has some problem using it. Break points stop working.
I switched to UeStudio from IDM but can not get a debugger to work. I created a project to use the compilers from Microsoft Visual Studio 10.0. UeStudio is supposed to use an integrated debugger. It downloads WinDbg.exe but it wont start up. The only WinDbg I found on Microsoft is from the Debugging Tools for Windows (x86) and (x64). It does not integrate with UeStudio. It starts up in a separate window. I have played around with it a bit but can not get it to load my DLL. I keep getting and error that it can not load my symbols (mismatching symbol file). I have set it to look were the '.pdb' for my plugin is located an doubled checked that it is correct. It's message names my DLL. I do not have symbols for the application. They do not supply one. I can load my source file and set Break points. But can not examine data.
Anybody get UeStudio debugging to work on windows 7? Or have any idea on debugging DLL on windows 7 cheaply.
I use OllyDebug.
OllyDbg
IDA is also very nice (paid)
I am trying to run my visual studio (2010) C++ project on an old Windows XP machine that is running VS2010. However, when I run it, I get the error listed in the title of this question. Why is this, and how can I fix it?
Same error was throwing for me when I had Silverlight debugger enabled. To resolve this issue
Open project properties
Under web tab look for Debuggers
Remove the tick mark on "Silverlight"
In general, a debugger should be the same bitness as the debuggee (or at least it must be able to understand the architecture of the target). In any common siutation, an x86-based debugger will not be able to debug an x64 application.
The Visual Studio documentation says:
To debug a 64-bit application that is running on a remote computer,
you need to install the 64-bit remote debugger on the remote computer.
The 64-bit remote debugger is available on the last disc of your
Visual Studio installation set.