0:025> !pe
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_<arch>_<arch>_<version>.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.
After corflags.exe /32bit+ xxxx.exe to run on a 64bit server 2003, the xxxx.exe usually crash. I got this dump, on the same machine, install windbg(x86), but I can't use SOS. I googled this issue, but can't find work answer. I use the same machine, why windbg can't find what it need?
The problem is that the correct version of mscordacwks.dll can't be located. The DLL acts as an abstraction layer between the runtime and SOS and thus it must correspond to the version of the runtime. There's an excellent write up of the problem and its solution here http://blogs.msdn.com/dougste/archive/2009/02/18/failed-to-load-data-access-dll-0x80004005-or-what-is-mscordacwks-dll.aspx
Make sure to follow the advice on renaming the DLL very carefully, cause if you get it wrong it doesn't work and the error messages are not very helpful imo.
Related
Using WinDbg to debug a .NET dump, command !clrstack gets a warning:
*** WARNING: Unable to verify checksum for PresentationFramework.ni.dll.
I have set the symbol path to SRV*D:\MsSymbols*http://msdl.microsoft.com/download/symbols. How to solve this warning and how to load the matching SOS and CLR?
The *.ni.dll are native images, i.e. a .NET DLL that has been pre-compiled by ngen.exe for your PC. Since this was compiled on your machine, there won't be symbols for download from the Microsoft server. Nothing to worry about.
Regarding the version of SOS and MSCorDacWks, it depends a little bit.
a) you were loading a specific version using .load x:\path\to\sos.dll. In that case, try loading SOS with .loadby sos clr. If that works, you were lucky.
b) if you have loaded SOS with .loadby sos clr already, you have created the crash dump on a different machine. In that case you need get the exact version of SOS and MSCorDacWks. This can be achieved by
b.1) run .unload sos and !analyze -v. If often downloads a correct SOS version and stores it somewhere in the symbol path.
b.2) go to the machine and find the files manually
b.3) use MsCorDacWks Collector and run it on that machine. It will grab all available versions of SOS and MSCorDacWks. Disclaimer: I'm the author of that tool.
b.4) If the machine is no longer available, have a look at my SOS archive. You're unlucky this time, but there's at least a very close version 4.7.2116. Disclaimer: I'm the maintainer of that archive.
My problem might seem specific, but in fact it is probably very general: How to publish a Console Application that uses 3rd party references?
I am using Visual Studio 2015 to make a Console Application called Gdx2PostgreSql programmed in Visual Basic. The application is reading data in a Gdx-file (output from a GAMS program, www.gams.com) and writing the data to a PostgreSql database. The interface to PostgreSql is handled by NpgSql, www.npgsql.org. NpgSql is referenced as
\\dtu-storage\hela\Documents\Visual Studio 2015\Projects\GDX to PostgreSQL 2\packages\Npgsql.3.1.7\lib\net451\Npgsql.dll
The program functions correctly when it is executed in Debug mode inside Visual Studio.
I have to be able to run the program from the command prompt in a CMD window. Moreover, I have to be able to run the program by spawning from a GAMS program using the GAMS syntax
Execute 'Gdx2PostgreSql "FileName.gdx" "CaseName"';
I have published the program and run the setup file installing the program. But when I run it in a CMD window I get the error:
'Gdx2PostgreSql' is not recognized as an internal or external command, operable program or batch file.
I get the same error message when spawning from my GAMS program.
Being rather desperate I have tried renaming the file setup.exe in the Publish-folder to Gdx2PostgreSql.exe. When I use this file I get:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Npgsql, Version=3.1.7.0, Culture=neutral, PublicKeyToken=5d8b90d52f46fda7' or one of its dependencies. The system cannot find the file specified.
That is, NpgSql is not known to the program.
As I see it, I need to have one EXE-file that holds all what is needed - especially because my program should be able to run on other PCs, too.
Can anyone help me make my program Gdx2PostgreSql function?
Finally, I should mention that I have made other programs reading Gdx-files and using NggSql to write to PostgreSql. These programs function correctly, but they are Windows Forms Applications – and not Console Applications.
Console applications aren't really any different from winforms applications - you have to distribute the EXE along with any DLLs it depends on - in the same directory. As mentioned in the comment, after building your program you should be able to find everything you need under bin/Debug (or Release).
Regarding why your Gdx2PostgreSql isn't being found, that's likely a problem of path - try running your program with an absolute path, or cd'ing into bin/Debug (or Release) before executing it.
I'm having trouble cross compiling PostgreSQL for my TI Sitara AM335x EVM SK. My host system is an i386 machine running Ubuntu 12.04.
My application is written in C++ using Qt. When I try and compile, I get the error that libpq.so is incompatible. I believe this is because the cross compiler is trying to use the host libpq.so instead of one for the target system (which as I have found out, doesn't exist).
I've downloaded the source for PostgreSQL with the intention of cross compiling that in order to give me the libpq.so library that will be compatible with my target system, however there is virtually no information on how to do this.
I have tried using the CC argument with the configure file to change my compiler to the following: CC=/home/tim/ti-sdk-am335x-evm-06.00.00.00/linux-devkit/sysroots/i686-arago-linux/usr/bin/arm-linux-gnueabihf-gcc but the configure script gives me this error: configure: error: cannot run C compiled programs. If you meant to cross compile, use --host.
The configure file makes a small reference to the --host option, but the only information in the file that I could find is in reference to mingw and windows, which isn't what I want.
I've done some quick searching through the configure file, and it references the --host option, but with no explanation of what is a valid host. I'm assuming that with --host option there will be an associated --target.
What arguments can I give the configure script so that it will cross compile with the correct compiler to generate a library that my target device can use? Are there any resources out there that I haven't found in regards to how the --host/--target works or how to use them?
OK, so after fiddling around for a little while, I think I was actually able to cross compile PostgreSQL and answer my own question.
Before I went any further, I had realized I had forgotten to add the path to my cross compiler to the PATH environment variable. I used the command export PATH=/path/to/cross/compiler:$PATH to insert the compiler path to the PATH environment variable.
Next, I did some experimenting with the --host option. To start off with I tried using ./configure --host=arm-linux-gnueabihf and running the configure script. The configure script seemed to accept this as the host argument. I then went to the next step of running the makefile. Running this makefile resulted in errors being generated. The errors were selected processor does not support Thumb mode. I did a quick search to see what information I could find about this error and came to this webpage: http://www.postgresql.org/message-id/E1Ra1sk-0000Pq-EL#wrigleys.postgresql.org.
This webpage gave me a bit more information since it seemed like the person was trying to do something very similar to me. One of the responders to the post mentioned that --disable-spinlocks is intended for processors that aren't supported by default by PostgreSQL. I emulated the arguments that were used in the website listed above and used the command: ./configure --host=arm-linux CC=arm-linux-gnueabihf-gcc AR=arm-linux-gnueabihf-ar CPP=arm-linux-gnueabihf-cpp --without-readline --without-zlib --disable-spinlocks to generate my makefile. This makefile actually generated all of the files, including the libpq.so library file I was needing.
Hope this helps somebody else in the future!
I have memory related problem in my application on solaris9 environment where Tcl_DeleteInterp() function calls lot of free() and mutex_unlock() functions. To debug the problem i followed the below steps to compile tcl on solaris server (with TCL_MEM_DEBUG flag) but still i couldn't use the 'memory' command in my interpreter.
Ran configure script on server (./configure –prefix=<directory needs to be installed> --enable-symbols=mem)
Make clean all
Make install (tcl libraries and tlcsh exe is copied to the path specified in step1)
Compilation generated two libraries (libtcl8.4g.so and libtclstub8.4g.a), I copied libtcl8.4g.so as libtcl8.4.so to my app
Copied tcl8.4 directory as well.
I also copied the tclsh8.4 to $PROVHOME/bin and created soft link as tclsh-> tclsh8.4.
From my application i linked the debug symbol enabled libraries to the place where exactly i created the Tcl interpreter.
Initialized the Tcl interpreter to using Tcl_InitMemory() function (so that the memory command will be registered in the supplied(arg) interpreter.
When i used the interpreter exe (tclsh) separately i could execute the memory command, but when i used the same exe on my application its not working. Can someone help me what could be the possible reason for this problem ?
Also help me how can i cross verify the libraries that they are compiled with TCL_MEM_DEBUG flag.
Will the Tcl source code tar file contain Solaris directory where i have to build the libraries or should i use the unix source code for solaris platform as well ?
Thanks
Are you using [mem] interactively (which does expansion of unambiguous short command names) and forgetting to use the full name ([memory]) in your scripts?
You're using Tcl embedded in your code? You need to call Tcl_InitMemory (passing in the handle to the interpreter where you want the memory command created) after creation of the interpreter and before you run user scripts, i.e., straight after the Tcl_CreateInterp gives you the handle (which should in turn come after the Tcl_FindExecutable call that initializes the shared parts of the library).
You must also make sure that everything is built with that flag set so that the correct memory allocation APIs are used in both your code when it integrates with Tcl, and you must make sure that you are linking against the debugging build. It's probably the linking that has gone wrong, but I've not done that level of development on Solaris for many years.
I think you'll find that “Getting a list of used libraries by a running process (unix)” is relevant to your problems.
I have received a mini dump file from our network support team. They complain that one of our sites on the production node causes high cpu usage.
The Windows server is x64 but the IIS App Pool is running in 32-bit mode. The network/support guys have used the default task manager to create the dump file so I assume the dump file must be a 64-bit one.
I downloaded WinDbg x64. Then I tried to follow the instruction given in the link below to find which part of the code can be problematic:
site
Although the dump file and WinDbg both are 64-bit, when I run "lmvm clr"command, the debugger shows this line:
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
If I run this command:
.loadby sos clr
and then !pe command, I get "no export !pe found" (this happens with any other command such as !CLRStack).
If I get the 64-bit version of mscordacwks.dll and sos.dll, and copy them into the symbol folder, the libraries will be loaded but upon running !pe command I will get "Failed to load data access DLL, 0x80004005 error message!
What I am doing wrong? I asked the network team to send me the .dll files (sos.dll and mscordacwks.dll), I copied them to the symbols folder but nothing changed.
p.s. I have read all the similar posts but none helped.
Open the dump in a 32-bit debugger and run !wow64exts.sw. You should now be able to load SOS and run commands, though not all commands will work. This will help, but still the best solution is to gather the dump with a 32-bit tool.