Problem
I have a Windows application that we developed for in house use. Thanks to Windows Error Handling, the window stays open and I can easily generate a crash dump from the task manager.
I have used crash-dumps on linux through eclipse once before, but this is the first time on Windows.
Hardware
The server is Windows 2012, and my development machine is Windows 7.
Windbg
When I load the crash dump in Windbg, load my symbols, then choose to look at the call stack, the only listings are:
How can I see my application call stack specifically?
Looks like your applications is a 32Bit application and you used the 64Bit Taskmgr to generate a dump.
You should use ProcessExplorer instead, it cares about the bitness:
Process Explorer v15.3: It also creates dump files that match the
bitness of the target process
Or run the 32Bit Taskmgr from C:\Windows\SysWOW64 to generate the dump.
As already answered, you have taken a 64 bit dump of a 32 bit application. There are multiple options to take a 32 bit dump of a 32 bit application on 64 bit OS, just choose the one which is most comfortable to you.
If this is the only dump you have and there's hardly a chance to get a better dump, you can try !sw to switch to 32 bit mode:
0:014> !sw
Switched to 32bit mode
0:014:x86>
Note how the command prompt changed. IMHO the exact same effect can be achieved by .effmach
0:014> .effmach x86
Effective machine: x86 compatible (x86)
0:014:x86>
except that you specify the mode explicitly where the !sw command toggles between the two.
In case of a .NET application, none of these ever helped me, since SOS cannot work with dumps of incorrect bitness.
Related
I am a newbie to Windows device drivers. My immediate task is to take an existing 32 bit minifilter driver and port it to 64 bit Windows. My development environment is Windows 7/64 bit, Visual Studio 2012 Ultimate, DDK 7600.16385.1, and SDK 7.1A. The install package is a setup.exe created with InstallShield 2013.
I've found some doc on porting drivers to 64 bit, but it's all about code issues. I haven't been able to find an idiot's guide covering step-by-step instructions for everything else you might have to change, so I decided to take the naive try-it-and-see-what-happens approach and just recompile for 64 bit, with the one exception to that being code signing since I did read somewhere that Win64 requires signed drivers.
The pre-existing build for the driver project used DDKBuild.cmd, and I have modified the properties for the Win64 platform to specify ../scripts/build.cmd -WNETAMD64 free $(OutDir) on the build command line. The compile and link are successful. I've modified the InstallShield project to pull in the signed 64 bit code file instead of the 32 bit code.
The installation appears to run successfully on a 64 bit system (Win2008 R2). There's a two line script that runs during the install:
rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 .\xxxxxflt.inf
fltmc load xxxxxflt
The rest of our application is actually Java, which makes some JNI calls to a couple of DLLs, one of which calls FilterLoad(). (BTW, the JVM and the DLLs remain 32 bit, but my understanding is that 32 bit code should be able to load a 64 bit driver via FilterLoad(). Please correct me if I'm wrong.) The return from FilterLoad() was ERROR_FILE_NOT_FOUND, and that caused me to notice that, as stated above in the question, the xxxxxxflt.sys file had been copied into SysWOW64\drivers instead of System32\drivers.
I know this is wrong, because Win64 is oppositeland, so System32 is where 64 bit stuff should go and SysWOW64 is where 32 bit stuff should go. What I don't know is why it ended up there. Are there changes necessary in the .inf file in order to identify this as a 64 bit driver? Is there anything I might have to do in the InstallShield project to tell it to build a 64 bit installer or run scripts in a 64 bit engine? Does the script have to do something to force use of the 64 bit version of rundll32? Something else, perhaps?
I haven't seen this specific problem, but I've had issues with this type of "WOW64" thing before. It usually means there is something within your software that is 32-bit and is being run in that mode, so anything you do will end up in the a "Program Files (x86)" or "WOW64" type location. Here is what I think might be happening:
This could have something to do with the way you are calling rundll32.exe. See the following post:
rundll32.exe equivalent for 64-bit DLLs
It's possible that if your InstallSheild installation is creating a 32-bit executable then it is running in WOW mode already which means that it's probably choosing the rundll32.exe that is in the WOW directory, thus the reason your installation ends up there too.
You might look at modifying your script to call the specific one based on the platform, or see if you can change your InstallShield to run as a 64-bit application in non WOW64 mode.
I tried to learn "Lena's reversing for newbies", when some trouble arise.
I start Pixtopian Book with ollyDbg, then try to have MessageBox with message about uregistered version.
Then i switch to OllyDbg, stop program executing and press "Alt+F9" for "Back to user mode" which stop the program after it exit from DLL.
But after this program does not work, it's frozen and does not respond to my actions.
If i turn off "Back to user mode" program normally work.
What's the problem? Can i try to use "Back to user mode" in IDA (uses WinDbg) or some other debugger and How i can do this? Can i repair it function in OllyDbg?
P.S. It's like the program stopped and didn't run after use "ALT+F9".
/Sorry for my English, i'm just learning ;-)/
First of all, Ollydbg is meant for 32 bit platform. It means that it will run only on a 32 bit OS and can only debug 32 bit apps.
In x64 Operating Systems (specifically Windows) there is a feature called compatibility mode that lets you run 32 bit apps. The 32 bit code is either run by emulation or natively (when the hardware itself implements the instruction set and then it is called x86-64).
So, when you try to run Ollydbg in a x64 environment it will run, but you will experience problems like the one you are facing. It occurs because Ollydbg is run in an emulation mode. Being a debugger it needs access to the registers and other system structures, which it is denied. What it can see is a virtual image of the system.
So the solution to the problem is using a Virtual Machine.
You would install a 32 bit OS in it and debug the app using Ollydbg. As far as Virtual Machines are concerned, I would recommend VMWare. You can use either the workstation or player version. The latter is free but does not support snapshots.
Other solutions are Virtual Box, Parallels Workstation and Microsoft Virtual PC.
The disadvantages of them are that Virtual Box does not support hardware breakpoints, Parallels Workstation is no longer supported as of 2014 and moreover there you would get a BSOD if you try to single step through FPU instructions. I have not tested Virtual PC though.
Note : Ollydbg does not supports x64 but its author is working on a x64 version.
I just learned how to update changes to the exe file for ollydby v 2.01e.
suppose I wished to change a jl command to a jmp; do this by clicking the executable modules button, choose the file and right click to view the file. then record the changes and save file. The saved file also has a backup in case something goes wrong.
I just did a thorough learning of the pixtopian file. When I downloaded
that tutorial I get the file pixtopian107.exe only. Since it didn't agree with the tutorial I investigated further. That file is an installation file. It produces a regular pixtopian.exe file which is the file you wish to play with.
I also noticed that in running the file it never enters the main module.
this is because of the TLS callback. right now I am trying to learn how
to overcome this which is how i came to this site in the first place.
I am using ollydbg vs2.01e very effectively.
Another thing, in vs 2.01e I am still trying to save changed data. Until I succeed I am recording the changes in the exe files using hex editor.
From my experience I can tell that this functionality won't work on Windows 7.
On Windows 7 64bit --> Won't work at all.
On Windows 7 32bit --> Will work partially, but only when using option "File>Attach" in OllyDbg.
For me, best solution was to use Windows XP 32bit, then it worked fine.
Kind of a complicated question that I can't properly summarize in the title.
I have a 64 bit process (Foo64) that creates a 32 bit child process (Bar32), then tries to get the full path of Bar32's version of kernel32.dll. Obviously I expect Bar32 to have loaded it from C:\Windows\SysWow64\kernel32.dll
On Windows 7, I call GetModuleFileNameExA() from Foo64, and correctly get "C:\Windows\SysWow64\Kernel32.dll" back.
On Windows Server 2012, the exact same code gives me back "c:\Windows\system32\kernel32.dll", which is the 64bit dll location. It's obviously not possible for Bar32 to have loaded a 64 bit dll.
My hunch is that Server 2012 is telling me the location of where Bar32 tried to load it from, rather than the actual redirected location. How can I get it to tell me the true location?
Is there something fundamental I'm misunderstanding?
I have read all of the relevant MSDN pages, and the first three pages of all relevant google searches.
I recently received a 64-bit crash dump from a customer.
Our processes are all 32-bit, but the customer's machine is running x64 Server 2008.
Visual Studio (both 2008 and 2010 Express) is telling me that I have to use the 64-bit version of MSVSMON.EXE, which I can't because I don't have a 64-bit machine.
I'm pretty sure there's a way to do this in WinDbg, but I find WinDbg to be hostile.
Is there any way to debug a 64-bit dump on a 32-bit machine, preferably using Visual Studio?
You need to make sure that customer uses 32 bit tools (adplus or DebugDiag) to capture crash dumps for your 32 bit processes. Then you can use your 32 bit machine to debug the dumps.
Link
Though Isalamon's comment is technically correct, nobody would like to execute that as the stack trace is horrible.
Let your customer know that this is necessary, and hope that he/she cooperates.
If you are not familiar with dump analysis, Microsoft is always there for you, http://support.microsoft.com
I worked around the problem by using 32 bit task manager (C:\Windows\SysWOW64\Taskmgr.exe) to capture the dump.
I have gotten excellent results using the advice on switching to x86 mode using !wow64exts.sw as advised here:
http://blogs.msdn.com/b/ntdebugging/archive/2008/06/03/how-to-debug-wow64-applications.aspx
Same advice figures here:
http://blogs.msdn.com/b/msdnforum/archive/2010/03/14/how-do-i-switch-to-32bit-mode-when-i-use-windbg-to-debug-a-dump-of-a-32bit-application-running-on-an-x64-machine.aspx
And background and related commands over here:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa384163(v=vs.85).aspx
Hope this serves as a compilation of decent inputs on this topic in addition to what already exists in this thread. Thanks.
Is it Userdump or kernel dump? It looks like you got the system dump. If that is the case, then you can take help of !wow64exts extension on windbg and can root cause the problem.
I agree with anwer you should get dmp file captured correctly, but recently did some experiments with this type of incorrectly captured dmp file. I used WinDbg to patch SOS.dll to remove the arch check. I'm not 100% sure if what I'm getting is valid, but at least some it appears so... https://chentiangemalc.wordpress.com/2015/04/17/experimental-use-of-64-bit-dump-of-32-bit-net-process-in-windbg/
Is there a way from a 32bit application running on a 64bit system to have access to the default folders for 64bit applications?
For example, using SHGetSpecialFolderPath with CSIDL_PROGRAM_FILES from a 32bit application returns "C:\Program Files (x86)' If the same call was used from a 64bit application, I would get "C:\Program Files". Is there a way of getting that "C:\Program Files" from a 32bit application?
A related question here does not help SHGetFolderPath() 32 bit vs 64 bit nor does supressing the wow64 filesystem redirection before calling SHGetSpecialFolderPath
Answering my own question, it seems it is not possible with SHGetSpecialFolderPath. In Vista and later, using the replacement function SHGetKnownFolderPath allows it with FOLDERID_ProgramFilesX64
I believe the whole reason for having separate folders was to prevent 32 and 64 bit applications from mixing. Therefore, you shouldn't need to see a folder belonging to a different bitness from your application.
You may have a very good reason, but I don't see one in your question as posted.