Hi,

I'm using SI 4.05 under win98 and everything works fine. But I noticed that SI sometimes leaves nasty "int 3" instructions at the places where I originally put my breakpoints.
When and how that happens is difficult to describe, but whoever experienced it will know what I mean. The only way to get rid of these pseudo int 3 instructions is to reboot. My simple question is:

Is there a simpler, better way to remove those pseudo int 3 instructions ?

Many thanks,

MrSmith

Int3.. Int3.. Where are thou from ?

Oh well, SI sets an Int3 in your code ( in mem) at the place where you want to break.. when you finally break it writes the real bytes back to place. If you dump the prog it can happen that all your set breakpoints are still Int3's...

(Puh - shitty explication )

Anyway... before you dump you should always disable all your breakpoints using " bc * "


Did you try " faults off " ? All the prog should do is crash then... no need for rebooting.

..JC..

> If you dump the prog it can happen that all your > set breakpoints are still Int3's...

No no, I'm not talking of dumping.

I'm talking about stepping through and setting breakpoints in a normal, unpacked program.
It happens like this: You set a bpx, run the prog (F5), that breaks and you press F5 again without removing the bpx. Now the prog continues and runs normal. If you then exit the prog and go back into softice to remove the bpx after the prog has terminated, then I sometimes come across this problem. If I now start the program, without SI, it crashes. And if I use SI to look for the reason (starting it with the SI loader, disassembling some code) I see that at the position where my original bpx was there is now the int 3 instruction left, which SI inserted earlier.

I "guess" when I start a prog by double clicking on it win98 doesn't always load it freshly from disk. If the prog just terminated win98 might keep it in memory for a while so that it can be restartet much faster if the user starts it again.
If this is true, then it might be that the manipulations SI did to the prog in memory (like inserting int 3) make trouble even when I start it again by double clicking. Rebooting helps because it obviously gets rid of everything what is in memory.

Phew, this was a lot of typing. I just hope it makes things clearer and not worse.

MrSmith

Hiya,
Its a fairly common occurrence with Visual C programs if you EXIT the program without disabling the breakpoints. Solution is usually as JC says, disable breakpoints or use bpmb address x instead of bpx address. Never had it happen in anything other than VC proggies.
regards

The rumor has it( sorry I don't remember whom to credit here ) that there is an elusive bug in S*ftICE ( some
versions ? some Win versions ? ) that could cause these
problems to creep in :
- a page , into which S*ice has put an int 3 ( bpx ) ,will
get paged to disk and ultimately written back to the
original .exe disk file without s*ice noticing it , so that
the EXE might be corrupted .

I have not yet noticed the phenomenon myself , but
just in case - I would advise debugging only A COPY
of an original exefile (or dll !) Otherwise , in case that bug is real - and it might well be a consequence of Win
9x's and/or NT's treatment of "file mapping" - then you'll
end up quickly with crucial files subtly corrupted :~(
in a sense that would be an example of "immanent justice" , an implied punishment for our "crimes" ;=)

Another hint : use a BPM X whenever you can instead
of BPX : I wonder why so many would-be hackers
still use 'int 3' type BPs as though they were still
debugging on a 80286 ( BTW , I am still operating 2 80286-AT clones , and I LOVE them - but that's another story ...) . On a 80386 + , "int 3" BPs are necessary
ONLY if the code you are debugging might "roam" inside
memory space , or once you have exhausted all the four
HW breakpoints ( clear or disable one of these others )

HTH

--
Czerno

hmmm that was a pretty strange bug in older versions of soft-ice + combination of windows (i didn't came across that in w98se, yet) but i had the situation pretty often in w95...

as this previous guy already told u, better go and use bpms or bpr instead of bpx (or another debugger

^DAEMON^

That is almost true howewer it wont corrupt original exe it only corrupts chashed one.

For example when you make some changes to the program (in memory) and the decide to backup it before aplying them to file you may find that file is already changed and backup is corrupted too, but if you reboot- original file will be fixed, but copy wont. ints also remain in file causing crashes when trying to run it.

Solution: make backup BEFORE starting your work then you will be able to overwrite corupted original thus refreshing chashe.

For safety reasons dont try to patch file after you used softice on it you may completely damage it by writing all that damaged content to disk.

Hi everybody !

The search function did it again. We had this problem already in this (http://www.woodmann.net/forum/showthread.php?threadid=243) post some time ago.