I am analyzing a memory dump of an IIS worker process running on a Windows Server 2008 on my Windows 8 workstation. The dump is a mini dump taken using task manager.
The .Net Framework versions on server and workstation differ:
Workstation: 4.0.30319.18046
Server where the dump was taken: 4.0.30319.296
I copied sos.dll and mscordacwks.dll from the server to my workstation in a dedicated directory, then opened the dump in WinDbg.
Symbol File Path: SRV*c:\dev\symbols*http://msdl.microsoft.com/download/symbols
Then I load the sos.dll copied from the server:
0:000> .load D:\temp\dumps\sos.dll
This allows me to list the threads using !threads or watch stacks using !clrstack.
But when using !pe or !clrstack, I get a version mismatch warning:
0:000> !pe
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: 4.0.30319.296
The current thread is unmanaged
While I could see the stacks that interested me, I'm confused about the CLR Version in the warning: Where does this version come from?
The dump indicates version 4.0.30319.1 when I execute
lmv m clr
But 4.0.30319.1 is used nowhere in this case, neither on server nor workstation.
Or am I missing something?
Additionally, WinDbg loads the symbol files for mscordacwks_AMD64_AMD64_4.0.30319.01.dll to my symbols directory.
Output of .cordll:
0:000> .cordll -ve -u -l
CLRDLL: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll:4.0.30319.18046 f:8
doesn't match desired version 4.0.30319.01 f:8
CLRDLL: Loaded DLL c:\dev\symbols\mscordacwks_AMD64_AMD64_4.0.30319.01.dll\4BA21EEB965000\mscordacwks_AMD64_AMD64_4.0.30319.01.dll
CLR DLL status: Loaded DLL c:\dev\symbols\mscordacwks_AMD64_AMD64_4.0.30319.01.dll\4BA21EEB965000\mscordacwks_AMD64_AM D64_4.0.30319.01.dll
I also tried to copy clr.dll from the server to my workstation and load the runtime using .cordll, but without success:
0:000> .cordll -u -lp D:\temp\dumps
CLRDLL: D:\temp\dumps\mscordacwks.dll:4.0.30319.296 f:8
doesn't match desired version 4.0.30319.01 f:8
CLRDLL: Unable to get version info for 'D:\temp\dumps\mscordacwks_AMD64_AMD64_4.0.30319.01.dll', Win32 error 0n87
CLRDLL: ERROR: Unable to load DLL D:\temp\dumps\mscordacwks_AMD64_AMD64_4.0.30319.01.dll, Win32 error 0n87
CLR DLL status: ERROR: Unable to load DLL D:\temp\dumps\mscordacwks_AMD64_AMD64_4.0.30319.01.dll, Win32 error 0n87
Can anyone shed some light on this versioning issue? Is it somehow related to the type of dump used?
Steps that worked for me (assuming process was 64 bit):
Copy C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll from server machine to local directory on your dev machine.
Copy C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll to the same directory where you copied sos.dll into. Then rename it to mscordacwks_AMD64_AMD64_4.0.30319.01.dll.
Load the copied version of sos.dll -- mscordacrwks will be loaded automatically.
In more details, the procedure is described here: http://blogs.msdn.com/b/salvapatuel/archive/2010/03/09/how-to-configure-windbg-to-run-other-versions-of-the-net.aspx?Redirected=true.
Related
This is something like the question WinDbg: Version mismatch of dbghelp.dll when trying to attach to a process
However, I can't post to that question and the marked answer isn't really an answer and doesn't work for me.
I have a machine which I used to use for debugging crash dumps, but suddenly it fails to open any dumps, always reporting
dbghelp.dll has a version mismatch with the debugger
Microsoft (R) Windows Debugger Version 10.0.14321.1024 X86
Copyright (c) Microsoft Corporation. All rights reserved.
command line: '"C:\Program Files (x86)\Windows Kits\Debuggers\x86\windbg.exe" -c ".cmdtree c:\cmdtree.txt"
dbgeng: image 10.0.14321.1024, built Sat Jul 16 09:31:09 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbgeng.dll]
dbghelp: image 10.0.14321.1024, built Sat Jul 16 09:29:50 2016
[path: C:\Program Files (x86)\Windows Kits\Debuggers\x86\dbghelp.dll]
DIA version: 40116
So it's complaining of a mismatch, but there is no apparent mismatch.
The version of dbghelp and dbgeng in System32 and SysWOW64 is 6.1.7601.17514. But note that:
a) According to Microsoft page on DbgHelp, the version in Windows and WinDbg does not need to be (and probably shouldn't be) synced
b) I have another machine where I have installed 10.0.14321.1024 version of WinDbg, and it also has version 6.1.7601.17514 of dbghelp and dbgeng in Windows folders, and everything's working fine on that machine.
Any assistance appreciated.
This machine is basically bricked as far as analyzing crash dumps is concerned. I've tried reinstalling windbg, and installing different versions, still the same error occurs.
I just installed Visual Studio Code and the DotNET Core SDK on a fresh Windows 10 32-Bit machine. However, I don't get it to run and to work properly.
I've loaded the csharp extension (Omnisharp) in Visual Studio Code. It is obvious that it seems to load x64 packages instead of x86:
[INFO] Starting OmniSharp at 'd:\Entwicklung\MyFirstApp'...
[INFO] Installing to C:\Users\Daniel\.vscode\extensions\ms-vscode.csharp-1.1.5\.omnisharp
[INFO] Attempting to download omnisharp-1.9-beta5-win-x64-net451.zip...
[INFO] Downloading to C:\Users\Daniel\AppData\Local\Temp\tmp-1252lY4HMeX6qNhB.tmp...
This leads to the error that the Debugger cannot be installed:
Error: Can not find runtime target for framework '.NETStandardApp,Version=v1.5' compatible with one of the target runtimes: 'win10-x86, win81-x86, win8-x86, win7-x86'. Possible causes:
1. The project has not been restored or restore failed - run `dotnet restore`
2. The project does not list one of 'win10-x86, win81-x86, win8-x86, win7-x86' in the 'runtimes' section.
Error:
System.InvalidOperationException: Can not find runtime target for framework '.NETStandardApp,Version=v1.5' compatible with one of the target runtimes: 'win10-x86, win81-x86, win8-x86, win7-x86'. Possible causes:
1. The project has not been restored or restore failed - run `dotnet restore`
2. The project does not list one of 'win10-x86, win81-x86, win8-x86, win7-x86' in the 'runtimes' section.
at....
How to fix this?
Thanks!
I have a netbook that I was hoping to use with Windows 7 32 bit and VSCode / Omnisharp and I have hit that wall as well.
Omnisharp only supports 64 bit at the moment. There is no known plan for a 32 bit version.
What is confusing is that it USED to be 32 bit compatible! Either make the switch to 64 bit (if your hardware allows it) or set up a different tool chain (perhaps using SharpDevelop?).
People have already requested this change but the devs don't seem to take it seriously.
What I did so far
I read the installation guide.
Installed OpenSSL library for Windows after downloading a setup file.
Downloaded and extracted a Mongo C Driver directory from GitHub.
Installed CMake for Windows after downloading from CMake web site.
Went to mongo-c-driver/src/libbson and run cmake -G "Visual Studio 14 2015 Win64" and it prints (maybe) success.
D:\works\test\mongo-c-driver\src\libbson>cmake -G "Visual Studio 14 2015 Win64"
Current version (from VERSION_CURRENT file): 1.4.0-dev
Previous release (from VERSION_RELEASED file): 1.3.5
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- Looking for snprintf
-- Looking for snprintf - found
-- Looking for _set_output_format
-- Looking for _set_output_format - not found
-- Performing Test BSON_HAVE_TIMESPEC
-- Performing Test BSON_HAVE_TIMESPEC - Success
-- struct timespec found
-- Configuring done
-- Generating done
-- Build files have been written to: D:/works/test/mongo-c-driver/src/libbson
Executed msbuild ALL_BUILD.vcxproj and prints the success.
The problem
Went to mongo-c-driver and run `cmake -G "Visual Studio 14 2015 Win64" and prints errors like this.
-- Found BSON: BSON-NOTFOUND;ws2_32
-- Found OpenSSL: optimized;D:/apps/OpenSSL-Win64/lib/VC/ssleay32MD.lib;debug;D:/apps/OpenSSL-Win64/lib/VC/ssleay32MDd.lib;optimized;D:/apps/OpenSSL-Win64/lib/VC/libeay32MD.lib;debug;D:/apps/OpenSSL-Win64/lib/VC/libeay32MDd.lib (found version "1.0.2h")
-- Searching for sasl/sasl.h
-- Not found (specify -DCMAKE_INCLUDE_PATH=C:/path/to/sasl/include for SASL support)
-- Searching for libsasl2
-- Not found (specify -DCMAKE_LIBRARY_PATH=C:/path/to/sasl/lib for SASL support)
-- Configuring incomplete, errors occurred!
See also "D:/works/test/mongo-c-driver/CMakeFiles/CMakeOutput.log".
I looked for sasl.h from my disks but there is none. I also looked for it from OpenSSL GitHub but it does not have sasl.h
I downloaded and opened cyrus-sasl from here, but I am stuck with it. I don't know what to do with it.
How can I do the successful build of MongoDB C Driver?
It appears that the libsasl2 port to Windows is not complete. Although I did ultimately get libsasl to compile, there was no libsasl2 produced. It appears that SASL is used by MongoDB C Driver for Kerberos. I don't know if they have tried to get Kerberos working with the C Driver on Windows without a port of the libsasl2 library.
I was, however, able to get the MongoDB C Driver to ultimately compile. I initially tried to compile using subdirectories of C:\, as opposed to C:\mongo-c-driver etc., but that didn't work well, but when I compiled using the directory structure in the documentation, the compile succeeded.
To get it to compile, I disabled the SASL library in the compilation. I don't think it will be needed unless you need to use Kerberos. I initially had to explicitly disable SASL (perhaps because of using 64 bit) -- that can be done with -DENABLE_SASL=no when compiling the mongo-c-driver.
Here are the steps:
Got driver source from this page: https://github.com/mongodb/mongo-c-driver/releases (1.3.5)
Got cmake from https://cmake.org/download/
Installed cmake using the Windows installer, adding cmake to the path for all users. I had to log out and log back in to get the path to update.
Then, I copied the mongo-c-driver-1.3.5 source to c:\mongo-c-driver-1.3.5
Then,
I used the Visual Studio MSBuild Command Prompt, started with Run As Administrator
C:\mongo-c-driver-1.3.5\src\libbson>cmake -DCMAKE_INSTALL_PREFIX=C:\libmongoc -G "Visual Studio 14"
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:3 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:3 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "C:/mongo-c-driver-1.3.5/src/libbson/CMakeFiles/CMakeOutput.log".
See also "C:/mongo-c-driver-1.3.5/src/libbson/CMakeFiles/CMakeError.log".
Turns out that the C compilers are not installed with a standard installation of Visual Studio, so I had to install C++ component of Visual Studio. I installed C++ Common Tools, but not MFC for C++ nor XP Support. That said it would use 3 GB of disk space (started at 39.5, ended at 37.0, so 2.5 GB used)
Once that was installed:
cd \mongo-c-driver-1.3.5\src\libbson
cmake -DCMAKE_INSTALL_PREFIX=C:\libmongoc -G "Visual Studio 14" .
msbuild.exe ALL_BUILD.vcxproj
msbuild.exe INSTALL.vcxproj
cd ..\..
C:\mongo-c-driver-1.3.5>cmake -DCMAKE_INSTALL_PREFIX=C:\libmongoc -DENABLE_SSL=WINDOWS -DBSON_ROOT_DIR=C:\libmongoc -G "Visual Studio 14" .
-- The C compiler identification is MSVC 19.0.23026.0
-- The CXX compiler identification is MSVC 19.0.23026.0
-- Check for working C compiler using: Visual Studio 14 2015
-- Check for working C compiler using: Visual Studio 14 2015 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 14 2015
-- Check for working CXX compiler using: Visual Studio 14 2015 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found BSON: C:/libmongoc/lib/bson-1.0.lib;ws2_32
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES OPENSSL_INCLUDE_DIR)
-- Searching for sasl/sasl.h
-- Not found (specify -DCMAKE_INCLUDE_PATH=C:/path/to/sasl/include for SASL support)
-- Searching for libsasl2
-- Not found (specify -DCMAKE_LIBRARY_PATH=C:/path/to/sasl/lib for SASL support)
Current version (from VERSION_CURRENT file): 1.3.5
-- Configuring done
-- Generating done
-- Build files have been written to: C:/mongo-c-driver-1.3.5
OpenSSL was not present, so I obtained 32 bit Win32 OpenSSL v1.0.2h from http://slproweb.com/products/Win32OpenSSL.html
Then, I installed OpenSSL. Changed installation directory to C:\work\OpenSSL-Win32, and I allowed the OpenSSL installer to install the binaries into the Windows system directory
Now,
C:\mongo-c-driver-1.3.5>cmake -DCMAKE_INSTALL_PREFIX=C:\libmongoc -DENABLE_SSL=WINDOWS -DBSON_ROOT_DIR=C:\libmongoc -G "Visual Studio 14" .
-- Found OpenSSL: optimized;C:/work/OpenSSL-Win32/lib/VC/ssleay32MD.lib;debug;C:/work/OpenSSL-Win32/lib/VC/ssleay32MDd.lib;optimized;C:/work/OpenSSL-Win32/lib/VC/libeay32MD.lib;debug;C:/work/OpenSSL-Win32/lib/VC/libeay32MDd.lib (found version "1.0.2h")
-- Searching for sasl/sasl.h
-- Not found (specify -DCMAKE_INCLUDE_PATH=C:/path/to/sasl/include for SASL support)
-- Searching for libsasl2
-- Not found (specify -DCMAKE_LIBRARY_PATH=C:/path/to/sasl/lib for SASL support)
Current version (from VERSION_CURRENT file): 1.3.5
-- Configuring done
-- Generating done
-- Build files have been written to: C:/mongo-c-driver-1.3.5
C:\mongo-c-driver-1.3.5>
msbuild.exe ALL_BUILD.vcxproj
(lots of output, with some yellow warnings, but no red errors)
msbuild.exe INSTALL.vcxproj
And now the mongo-c-driver has been built. I can use it with Visual C++ to connect to my MongoDB server using ssl.
Now, I am trying to figure out how to get Embarcadero RADStudio C++ Builder to use the new mongo-c-driver. Just copying the .dll's into the application's folder results in an abort in the bson dll. The stack trace looks like this:
There are two errors in that output.
- libbson must be installed and available
- mongoc is configured against cyrus sasl, in which case it must be installed and available
Both are easily fixable, and later versions of mongoc will no longer error if cyrus sasl or openssl isn't available, but will instead use the Windows native implementations. The driver can also be configured without them.
The available configuration options and values are:
-DENABLE_SASL=[CYRUS|SSPI|AUTO|OFF]
-DENABLE_SSL=[OPENSSL|WINDOWS|DARWIN|AUTO|OFF]
Unfortunately the cmake installation of mongoc will not automatically install the bundled libbson for you, this may be fixed in the future, but for now you need to install it seperately.
In short, to install the mongoc driver on Windows:
Download & extract mongoc (https://github.com/mongodb/mongo-c-driver/releases).
mongoc releases comes with libbson sources so no need to download them seperately.
Enter the libbson directory, "src/libbson" and then:
cd c:/path/to/mongoc/
cd src/libbson
# Configure and install libbson
cmake.exe -G "Visual Studio 14 2015 Win64" \
-DCMAKE_INSTALL_PREFIX=c:/mongoc
msbuild.exe ALL_BUILD.vcxproj
msbuild.exe INSTALL.vcxproj # Installs libbson
cd ../.. # Go back to the root folder of the release sources
# Configure and install mongoc
cmake.exe -G "Visual Studio 14 2015 Win64" \
-DCMAKE_INSTALL_PREFIX=c:/mongoc \
-DCMAKE_PREFIX_PATH=c:/mongoc/lib/cmake \
-DENABLE_AUTOMATIC_INIT_AND_CLEANUP:BOOL=OFF \
-DENABLE_SSL=WINDOWS \ # Use Windows Native TLS, rather then OpenSSL
-DENABLE_SASL=SSPI # Use Windows Native SSPI, rather then Cyrus SASL
msbuild.exe ALL_BUILD.vcxproj
msbuild.exe INSTALL.vcxproj
With a current Visual Studio you can just open the project, build all and get your DLLs.
I used Community 2019
Make sure the Desktop development with C++ workload is installed, it includes CMake support
Choose Open, CMake, then select CMakeLists.txt from the root of the extracted source archive
Now you are already ready to "build all", but since the default debug build is not recommended, you should open CMake settings, use the green "+" button and select x86-Release (or x64, if required).
For Delphi users: the default DLL filenames are without the required "lib" prefix (libmongoc-1.0.dll), so edit the BSON_OUTPUT_BASENAME and MONGOC_OUTPUT_BASENAME variables accordingly.
Another hint: the Delphi installation contains the files in 2 places: bin & Redist\win32, bin64 & Redist\win64 - good luck!
1.17.0-rc0 x86 release drivers
https://gofile.io/d/0wJ4R4
this is the session of building exe file in matlab 7.1.
I think I have a problem with the compiler.
mbuild -setup
Please choose your compiler for building standalone MATLAB
applications: Would you like mbuild to locate installed compilers
[y]/n? y
Select a compiler:
[1] Microsoft Visual C++ 2008 Express in C:\Program Files (x86)\Microsoft Visual Studio 9.0
[0] None
Compiler: 1
Please verify your choices:
Compiler: Microsoft Visual C++ 2008 Express
Location: C:\Program Files (x86)\Microsoft Visual Studio 9.0
Are these correct [y]/n? y
*****************************************************************************
Error: Could not find the 64-bit compiler. This may indicate that the
"X64 Compilers and Tools" or the Microsoft Windows Software
Development Kit (SDK) is not installed. To build 64-bit binaries,
Microsoft Visual C++ 2008 Express Edition requires that these two
packages be properly installed.
*****************************************************************************
Trying to update options file: C:\Users\****\AppData\Roaming\MathWorks\MATLAB\R2010a\compopts.bat
From template: C:\PROGRA~1\MATLAB\R2010a\bin\win64\mbuildopts\msvc90freecompp.bat
Done . . .
>> mcc -m mainmain.m -o mainmain
Could not find the compiler "cl" on the DOS path.
Use mbuild -setup to configure your environment properly.
C:\PROGRA~1\MATLAB\R2010A\BIN\MEX.PL: Error: Unable to locate compiler.
Error: An error occurred while shelling out to mbuild (error code = 2).
Unable to build executable (specify the -v option for more information).
??? Error using ==> mcc
Error executing mcc, return status = 1 (0x1).
if the problem is with the compiler, how can I install another compiler?
I have windows 7 (64 bits) and I want that the exe file will work on windows operating system.
This is probably the result of one of two issues.
1) You don't have the Windows SDK installed (as indicated in the error message). According to this MathWorks page regarding supported compilers
Both Microsoft Visual Studio 2008 and Windows Software Development Kit (SDK) 6.1 must be installed. When installing Microsoft Visual Studio, you must choose "X64 Compilers and Tools" when installing Microsoft Visual Studio; this is not selected by default.
Now, keep in mind, this reference is for the most recent release of MATLAB, but I'm betting that this information is still relevant to your issue.
You can download the SDK here.
2) It's also possible that the compiler that you're using simply isn't supported for your release of MATLAB. See here for info on supported compilers for MATLAB 7.1.
Here is the tool stack: Installed on Windows 7 (x64) is Eclipse (Juno x64) with CDT and the SConsolidator plugin. Underneath is the TDM-GCC (x64) bundle installed with 64-bit support.
If I build a 64-bit application and debug it using Eclipse (which uses gdb bundled with GCC), it builds without error and debugs fine.
When I build a 32-bit application and try to debug it with Eclipse, it builds fine but gdb fails:
gdb: unknown target exception 0x4000001f...
Debugging it with the same gdb via command line works fine.
Any ideas on how to work around this?
FYI: Here are some warnings leading up to the gdb exception:
warning: `C:\Windows\system32\ntdll.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64win.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: `C:\Windows\SYSTEM32\wow64cpu.dll': Shared library architecture i386:x86-64 is not compatible with target architecture i386.
warning: Could not load shared library symbols for ntdll32.dll.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for WOW64_IMAGE_SECTION.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
I had a similar problem in a different scenario but i think the solution should be applicable here too.
I was gdb.exe downloaded from http://www.equation.com/servlet/equation.cmd?fa=gdb to debug a C++ program.
I first tried the 64-bit because my pc is 64-bit but I got the same error as Paul got above. Then I tried 32-bit gdb.exe and it worked.
I also followed the links that were given by Paul and there was also bundle available for 32-bit. So I assume the bundles depend on the type of application rather than the configuration of the platform. But, I doubt 64-bit bundle will work on 32-bit architecture. I haven't tried that and can't say for sure.
I suggest install the bundles that support 32-bit to debug a 32-bit application.