Re: [c-prog] Extract code

[Oğuzhan Filizlibay]

On 15/08/06, Thomas Hruska <[EMAIL PROTECTED]> wrote:







Pete Calvert wrote:> benthemnite wrote:> >> I have recently been working on a C++ game that uses the command>> prompt. I was using Bloodshed's Dev-Cpp compiler to make the game. I
>> was compiling the latest version of the game when my computer crashed>> with a blue screen. I rebooted my computer and found that the compiler>> had emptied my source file right before the blue screen. I have a
>> recent .exe but no source files. Is there anyway that I can extract my>> C++ code from the .exe?>>>> >>> Not to contradict what everyone has said, but if you have a debug 
> version of the exe, then you *may* be able to get some symbolic > information from the exe. But I don't know anything about the debug > options in Dev-Cpp, so I don't know if this is true.> 
> Try opening the exe in your debugger and see if it shows the source > code, if it does then you may be in luck. If not, then as everyone else > said, you're back to square one I'm afraid.> > Pete

NO! Do my approach first. Booting into the OS is the WORST thing you can do until you assess the damage. You've got more than just a lost .cpp file on your hands - more than likely you have a premature hardware 
failure scenario and need to get ALL your data off the hard drive as quickly and safely as possible. You want to maximize the chance of data recovery and minimize further losses. Every time you boot up, you 
reduce your chances significantly (50% the first time w/ exponential increase every subsequent boot).While the computer is off, formulate a plan _on paper_ to get all your data off the computer. Then execute that plan in a sequential fashion 
on a single boot in as short a time as possible. Preferably from a bootable CD or another computer (connect the hard drive to another PC but don't move the drive). Once your data is safe, figure out what is 
wrong (run various hardware diagnostic tools).I could be wrong, but I've seen hardware failure scenarios like this way too often when helping people diagnose what is wrong and most people do the worst things possible to make a bad situation worse. A BSOD at the 
wrong time is usually the most recent indicator that something is wrong with the hardware. Of course, BSODs are usually the point where the person _finally_ talks to me and tells me that they are "frustrated with 
that hunk of junk". I then get to tell them it _IS_ a hunk of junk but usually manage to recover almost everything they had lost. They then write me a check for whatever amount I say because they are overjoyed at 
not having lost anything important. In this case, the OP probably ignored previous signs that something was wrong. A data loss like this is not necessarily unrecoverable, but if you account for possible hardware failure, you have to be REALLY careful how you proceed. At the 
very least, the file system is corrupted and that corruption could spread to other parts of the drive. More than likely, the drive is about to die. Less likely is RAM corruption...but if that is the case, 
using another computer for the data transfer is a good idea. The least likely is CPU overheating - but check to see if the fans are working properly. Whatever the cause, all signs point to hardware failure. BSODs with data loss simply don't happen when you run a compiler.
BTW, to anyone who gets BSODs/random reboots (the latter is a BSOD, but WinXP has a default set to automatically reboot on BSOD), write down all 5 parts of the STOP code and whatever DLL/EXE is mentioned. You can 
search Google for the STOP code and whatever msdn.microsoft.com page shows up, that will tell you the meaning of the BSOD in English. About 50% of the time, you can figure out what actually is going on and fix it 
before the problem gets serious. The rest of the time, the STOP code is meaningless and is probably some driver rampaging through kernel memory.Backups are great. Backups are best done with TortoiseSVN because you 
get these really cool icons that tell you what hasn't been "backed up" (aka 'commit'ed) yet. Red exclamation = bad. Green checkmark = good.
--Thomas HruskaCubicleSoft PresidentPh: 517-803-4197Safe C++ Design Principles (First Edition)Learn how to write memory leak-free, secure,portable, and user-friendly software.
Learn more and view a sample chapter:http://www.CubicleSoft.com/SafeCPPDesign/


 
in addition all that has been advised, if you would like to have more information on why your system has crashed follow the below steps:
1. get windbg from microsoft
2. set the symbol path under the file menu, symbol file path: srv*c:\sym*http://msdl.microsoft.com/download/symbols
3. drag and drop your crash dump file from c:\windows\memory.dmp
4. !reload to reload your symbols
5. after symbols are loaded, issue !analyze -v on the windbg prompt
 
the above will get you more details on the crash, possibly the kernel mode driver that generated the stop error. once you know the component you can disable it in safe mode, check for an updated version of the driver. 

 
HTH,
Oguzhan 

__._,_.___





To unsubscribe, send a blank message to <mailto:[EMAIL PROTECTED]>.








   



  




  
  
  YAHOO! GROUPS LINKS



   Visit your group "c-prog" on the web. 
   To unsubscribe from this group, send an email to: [EMAIL PROTECTED] 
   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



  






__,_._,___