I'm using the GHC to build a haskell pogram for Windows with help of a speciefic (Haskell-)Library which is called citeproc-hs. On a 32Bit-Windows XP machine the application works just fine whereas on another Windows 7 64Bit environment (tested on 3 different PCs) a "function of that library reading a speciefic file (a "style" file) mentioned above just freezes without any error message. I use the same .exe file and nevertheless there is a different behaviour I cannot explain.
Are there maybe some known problems concerning 32Bit Haskell - compilations in an 64Bit environment or does anyone has an idea how I could solve this strange problem?
Thanks in advance!
I use GHC on 64 bit windows in production, and we don't seem to have any issues.
I would suggest upgrading. If the behavior continues, report a bug against GHC.
Can you run it interpreted mode? Probably citeproc-hs is guilty. Does it contains any C code? And of course, you may comment out line-by-line and see what goes wrong. Does "hello world" runs fine?
Related
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.
I need to use the debug command in Windows 64x for learning purposes. When I type the command debug in the cmd, I get the following message:
'debug' is not recognized as an internal or external command,
operable program or batch file.
As I understand from some previous posts that debug does not work in 64x systems. Is there any work around for this issue?
EDIT:
I am trying to write assembly code for learning. I am not allowed to use any other option for writing assembly code. I have to use DEBUG.
debug.exe is not available in any of the 64 bit windows versions. What are you trying to accomplish? One option for you may be gnu debug - http://www.sourceware.org/gdb/
I know this is an ancient thread, but others might have the same question.
In general to use legacy software, the CLEANEST way to do it is to use the build in Hyper-V. And then have PC-DOS 3.30 (or any suitable 16 or 32 bit OS) on that.
Make sure to use a DYNAMIC disk (vhdx). This allows the disk to be mounted in Windows simply by clicking the vhdx (when not in use by Hyper-V - no sharing), so this allows for simple transfers, without complex net-setup.
There are other alternatives such as DOSBOX, though to my experience their emulation have some bugs (e.g. on the ancient FCB-system - older than file-handles)
I know it's a very long answer, but I just saw your post now. Use the vDosPlus (http://www.vdosplus.org/) or vDos (https://www.vdos.info/) software to run 16-bit (MS-DOS) programs on Windows 64-bit.
Working on a game atm using Ruby, but due to the nature of how the game is coded Windows XP is proving to be a issue, as various tweaks can be done to make you faster than other players
so my intentions are to upon loading of the game detect if you are running windows XP, and if so fail to load any further.
This may seem harsh, but the advantages XP gives over Vista or Win7 etc is vast and is unbalanced.
Can any one help?
Here you find some solutions on how to detect the operating system:
How can I find which operating system my Ruby program is running on?
But I think, it only tells you, if it is Windows or not. So you have to do a second step:
If it is Windows, you could call the system command ver to detect the Windows Version (As you might know, system commands can be called using the `-Symbol).
`ver`
More information about this command are found here: http://www.windows-commandline.com/2009/01/find-windows-os-version-from-command.html
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/
I am performing this project but there is problem of program .
we chose a program based on the 'C' language that runs on window 98.
But we need to run this program in window 7. So same program will run or not?
if not then what to do.
Just try it:
.. at worst it won't work and shouldn't harm anything
.. at best it will function as it does in 98 and you're golden.
Whether or not it will have any real problems working as intended depends upon too many unprovided details.
One thing I can say: if it's a 16-bit application and your Windows7 installation is 64-bit (vice 32-bit), you're far less likely to succeed in getting it running. In that situation I recommend finding a modern program that supports the functionality you're after.
Maybe it will or maybe it won't. Windows 7 can run 16 bit applications in XP mode , but unless you can provide more information about the application or the source code there is no way to tell without simply testing.