If I have a process dump file, is there anyway of knowing if the dump was generated on a x64 machine or x86 machines?
You can use the .effmach command to know the architecture that the dump was created on. Note that there is the WOW64 scenario where the dump arch is x64 but you should actually debug it with a x86 approach (see !wow64exts.sw command).
0:000> .effmach
Effective machine: x64 (AMD64)
You can look at the environment variables. Output of command !peb, among other things, contains list of environment variables. If you see variables PROCESSOR_ARCHITEW6432 or ProgramW6432 defined, the OS is 64 bit. Otherwise, it is 32 bit.
Unfortunately, above answers don't work in most cases.
Dupmchk.exe will say "x86 compatible" for both x86 and x64 OS if the target process was built as x86 binary. And !peb command also gives you useless "PEB NULL..." for minidumps which we use most of the time.
You would better check the full path of "Kernel32.dll" since x64 OS will load "C:\Windows\Syswow64\Kernel32.dll" instead while x86 OS will load the plain "C:\Windows\System32\Kernel32.dll" for x86 executables. Loaded modules and their paths are recoreded in minidump and easily checked by dumpchk.exe, windbg and Visual Studio.
You can use the dumpchk.exe utility that ships with Debugging tools for Windows. Simply pass the dump file as the argument.
In the generated report, you'll have the OS version and the CPU flavor, for example :
Windows 7 Version 7601 (Service Pack 1) UP Free x64
Product: WinNt, suite: SingleUserTS
Related
I have used pp PAR::Packer to build a standalone exe file to run on a Windows machine.
Can somebody explain how to build a Perl script with all the dependent packages from this Windows machine to create a standalone file to be run on a Linux machine?
Generating a binary that runs on a Linux machine starting from a Windows machine is not possible.
You use the pp (from PAR-Packer) command probably quite in the same way as you did in Windows
pp -S -M Some::Module -M Some::Other::Module -o youBinary.bin Script1.pl Script2.pl ScriptN.pl
Things to note:
The -M flag might be necessary because sometimes the automatic finding of dependencies may not work (some of them are loaded dynamically at runtime so it's a bit trial and error until you get the good combination). Take special care when you see warnings like these when executing pp:
Use of runtime loader module Module::Runtime detected. Results of static scanning may be incomplete.
Use of runtime loader module Module::Implementation detected. Results of static scanning may be incomplete.
The posibility to pack several scripts into one binary. You can them create different symbolic links to that binary to execute the different scripts.
When a single input program is specified, the resulting executable will behave identically as that program. However, when multiple programs are packaged, the produced executable will run the one that has the same basename as $0 (i.e. the filename used to invoke it). If nothing matches, it dies with the error "Can't open perl script "$0"
Very convenient from time to time.
Be aware also of creating the binary on a machine with an "older" libc. If you do this on a bleeding edge linux, you will need a bleeding edge linux to run it too, making it less portable.
Note that even if your perl was built with a shared library, the 'Stand-alone executable' above will not need a separate perl5x.dll or libperl.so to function correctly. But even in this case, the underlying system libraries such as libc must be compatible between the host and target machines.
Enjoy your standalone Perl binary.
EDIT
Generating a binary that runs on a Linux machine starting from a Windows machine is not possible.
The Perl Packager scripts says that it can create executable that runs in same OS. Can I use it to create Win32 binary with linux machine? Or what should I use to create Win32 executable binary on linux from my script?
It is not possible to create stand-alone binaries for different platform than what you are currently running on. This is a generally hard problem since you would have to cross-compile all XS modules and perl itself. Not nice.
For example, if you would like to develop an application on Linux and ship it for both Linux/x86 and Win32/x86, it works well to set up a Virtual Machine with a Windows (XP or 2000 or whatever) and a Perl installation. On that machine, use PAR/pp to package your application for Win32.
On what platforms can I run PAR? On what platforms will the resulting executable run?
Win32 (95/98/ME/NT4/2K/XP), FreeBSD, Linux, AIX, Solaris, Darwin and Cygwin.
The resulting executable will run on any platforms that supports the binary format of the generating platform.
Win7 Service Pack 1
Matlab 2013b
Hello
I am trying to include a libfaad2.dll lib (which I got ready compiled) to Matlab so I can use the functions. I try this with the loadlibrary command.
But I get the error message
libfaad.dll is not a valid win32 application!
from matlab.
A short examination of libfaad2.dll with DependencyWalker (x64 Version) showed that it needs c:\windows\system32\Kernel32.dll. But there is also shown that 2 functions are not available in kernel32.dll
---> So I guess this is not a Matlab Problem
BUT the c:\windows\sysWow64\kernel32.dll includes the desired functions!
How can I tell matlab, or generally, that the libfaad2.dll file should use the sysWow64\kernel32.dll ?
Found a solution: Installing 32 bit version of Matlab and try with this. Worked at first try!
More detailed: Win7 has 2 different folders for system .dlls
C:\windows\system32: Here are all the .dlls for 64-bit software and not for 32!
C:\windows\SysWoW64: WoW64 stands for "Windows on 64-bit Windows", and it contains all the 32-bit binary files required for compatibility, which run on top of the 64 bit Windows.
Using 32-bit version, Matlab will use the SysWoW64 files. And that is the rigth kernel32.dll which contains all the functions needed!
I'm trying to install MCR on a virtual machine, Windows server 2012 (that doesn't have MATLAB).
I manage to send the file over and run the installation program.
It installs with no problem.
But then I still get:
Could not find version 8.1 of the MCR
Anyone has an idea?
I tried to do it as administrator as well, but doesn't matter.
Can I change some path or something manually?
The error message is also:
attempting to load mclmcrrt8_1.dll
On the machine you used to build the standalone, get the correct MCR version with the following command:
>> mcr
The WIN64 MCR Installer, version 8.2, is:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\win64\MCRInstaller.exe
MCR installers for other platforms are located in:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\<ARCH>
<ARCH> is the value of COMPUTER('arch') on the target machine.
Full list of available MCR installers:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\win64\MCRInstaller.exe
For more information, read your local MCR Installer help.
Or see the online documentation at MathWorks' web site. (Page may load slowly.)
Take the file it names and install it on the server. You must match the architecture too.
Here are links to the installers.
May I know if I can cross compile the Solaris x86 library from Solaris sparc server?
The source code is mainly in C++ (some C). I need to use the Solaris C++ compiler CC to compile. I understand that some compile or link flags are different between sparc and x86. I have done a check to make sure that the flags I used are common.
Is it possible to simply copy the library compiled in sparc to x86? Or I need to apply specific flag during compiling and linking?
Thanks,
The Sun/Oracle Studio C++ compilers do not support cross-compilation. You would need to use another compiler that does, like a specially built gcc.
Simply copying the library can't work - SPARC and x86 are very different instruction sets, with no binary compatibility between the two.
Even if you could cross compile the Solaris libraries on SPARC for x86, it would seem a lot simpler to just install the x86 compilers and libraries. The interdependencies of these libraries is probably so complex that such a project would probably not work.
What's preventing you from just downloading and installing the Studio software on x86 Solaris?
Oracle Sun Studio C++ compiler (CC) has --xarch option with big variety of architectures. There are: sparc, amd64, pentium_pro and various extensions/modifications. This flag should be provided for both compiler and linker if you compile and link in separate steps.
You can verify target architecture with file command; e.g:
bash-3.2$ file /usr/bin/CC
/usr/bin/CC: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, stripped
Please, refer to CC manual for details:
Sun Studio 11 C++ Man Page
I have a client who is requesting that we give them an MSI file instead of our normal EXE file for installation of our software. The client has users on multiple Windows operating systems (2K, XP, Vista). As stated in the title of the question, do I need to create a MSI specific to each OS or are MSIs generic enough to work on all of these operating systems.
.MSI files can work successfully on multiple OSes.
One caveat is 32-bit vs. 64-bit: you'll have to make the choice of do you want to natively support 64-bit Windows. Your options are:
1) One .MSI file for both 32-bit and 64-bit. You would mark the package as 32-bit in the Summary Information Stream. Files would get installed to the 32-bit equivalent targets in 64-bit Windows. (e.g. Program Files (x86), 32-bit HKLM/Software/WOW64, etc.)
2) Two .MSI files, one each for 32-bit and 64-bit. Different Summary Information Stream for each package. This way the 64-bit targets would be the native 64-bit targets in 64-bit Windows. (e.g. Program Files, HKLM/Software, etc.)
More reference: Using 64-Bit Windows Installer Packages
You might want to have an MSI for X86 and X64 but I do not think you should have one for each OS.