naides
October 10th, 2003, 23:01
More than a question,
I wish to share the experiences I have had with DS 3.0 and see if other ppl have had the same problems and perhaps provide suggestions.
I was working on an app in which the status 'registered' versus 'demo' is stored in a global dword flag in in memory so that:
cmp dword ptr [00543221], 00
jz good guy, full capabilities
. . . Else Nag Screen: program in demo mode
Nothing out of the ordinary.
I was using DS 2.7 (I had no reason to update to 3.0 if it did the job)
So the logical next step was to catch the code when it sets the flag at [00543221] to something different than 00. No problem, I placed a memory access breakpoint: bpmd 00543221 w.
No rocket science here.
Now, the bloody bp did not break. I was double, triple sure that the flag had been modified: I manually changed to 00000000 at the program entry point, and later when Sice broke in a bpx point I had placed somewhere later in the code, the contents at 00543221 would be changed to 00000001 (demo mode) at some point, but SoftIce did not catch it. ???
It happened in two different computers, an Athlon and a Pentium 4, both running WinXP.
It was puzzling. I tested similar bpm with notepad, for instance, and it did break, so this phenomenon appeared to be an idiosincrasy of the particular app I was debugging.
I remembered that DS2.7 had bad reputation with WinXP. We had to apply Kayaker's patch to allow apps to break at WinMain etc.
Looking in the Numega website they claimed that DS3.0 was fully compatible with WinXP so I decided to give it a try.
After a somwhat rocky installation (It kept detecting DS2.7 despite I had already uninstalled, so I had to manually remove all registry traces) DS 3.0 was up and running.
The new version appeared to behave better than 2.7: If one loads a module onto the Symbol Loader it indeed stops at the entry point without need for a patch (I guess they copied it from Kayaker
). Also the memory breakpoints behaved as expected.
BUT small problem: breakpoints to system DLL API ie: BPX messageboxA worked very erratically. Even when I know for a fact that the API is called by the app, Sice refuses to break. I have noticed that if I manually traced in the code near the vicinity where the API is called, then it suddenly 'sticks' and starts working from that moment on.
Anybody with similar experiences?
Is this a bug?
Is this intended?
Is this Documented? (Yes, I RTFM and found no references to the issue, but I know dick about memory mapping and other obscure lingo, so I may have been looking in the wrong places)
Ideas?
Add on:
I do set the bpm while I am in the memory space of the debugee, more specifically when the program breaks at entry point. For extra caution I also set the API bpxS while in the memory context of the debugee at entry point.
I wish to share the experiences I have had with DS 3.0 and see if other ppl have had the same problems and perhaps provide suggestions.
I was working on an app in which the status 'registered' versus 'demo' is stored in a global dword flag in in memory so that:
cmp dword ptr [00543221], 00
jz good guy, full capabilities
. . . Else Nag Screen: program in demo mode
Nothing out of the ordinary.
I was using DS 2.7 (I had no reason to update to 3.0 if it did the job)
So the logical next step was to catch the code when it sets the flag at [00543221] to something different than 00. No problem, I placed a memory access breakpoint: bpmd 00543221 w.
No rocket science here.
Now, the bloody bp did not break. I was double, triple sure that the flag had been modified: I manually changed to 00000000 at the program entry point, and later when Sice broke in a bpx point I had placed somewhere later in the code, the contents at 00543221 would be changed to 00000001 (demo mode) at some point, but SoftIce did not catch it. ???
It happened in two different computers, an Athlon and a Pentium 4, both running WinXP.
It was puzzling. I tested similar bpm with notepad, for instance, and it did break, so this phenomenon appeared to be an idiosincrasy of the particular app I was debugging.
I remembered that DS2.7 had bad reputation with WinXP. We had to apply Kayaker's patch to allow apps to break at WinMain etc.
Looking in the Numega website they claimed that DS3.0 was fully compatible with WinXP so I decided to give it a try.
After a somwhat rocky installation (It kept detecting DS2.7 despite I had already uninstalled, so I had to manually remove all registry traces) DS 3.0 was up and running.
The new version appeared to behave better than 2.7: If one loads a module onto the Symbol Loader it indeed stops at the entry point without need for a patch (I guess they copied it from Kayaker
). Also the memory breakpoints behaved as expected.BUT small problem: breakpoints to system DLL API ie: BPX messageboxA worked very erratically. Even when I know for a fact that the API is called by the app, Sice refuses to break. I have noticed that if I manually traced in the code near the vicinity where the API is called, then it suddenly 'sticks' and starts working from that moment on.
Anybody with similar experiences?
Is this a bug?
Is this intended?
Is this Documented? (Yes, I RTFM and found no references to the issue, but I know dick about memory mapping and other obscure lingo, so I may have been looking in the wrong places)
Ideas?
Add on:
I do set the bpm while I am in the memory space of the debugee, more specifically when the program breaks at entry point. For extra caution I also set the API bpxS while in the memory context of the debugee at entry point.
The Using SICE manual says breakpoints set in the upper 2GB address range will break globally and breakpoints in the lower 2 GB address space will break only if the address context is the same in which the BP was set. It goes on to say that SI will pop up if the BP is set in a shared code module like kernel32.dll. I've yet to see that happen. In fact, I have had to modify several progs and insert INT 3 so that I can be in the proper context to set a BP that will pop up. Even for the so-called "shared modules".