DS3 not breaking

Thanks also for the info hobgoblin i try`t to download the files from _http://msdl.microsoft.com/download/symbols but site will not load can you send me the symbols don`t know how big they are.Please let me know.

Thanks in advance.

ysco.

You can send it to [email protected]

Originally posted by wps8848
Just as mentioned by Satyric0n, using DS on Windows2k/xp/2003 is very annoying.

I don't see how having to call ATTACH one time per process is annoying. It's not difficult, it doesn't have to be done repeatedly... Just call ATTACH once per process name, very very easy. I don't see what the problem is.

I plan on trying hobgoblin's suggestion (thanks hobgoblin!), I will report here whether or not it works for me. (And to ysco, to get the symbols, either use Symbol Retriever that comes with SoftICE, or go to hxxp://www.microsoft.com/whdc/ddk/debugging/symbols.mspx and download Microsoft's debugging tools)

Satyric0n

Let me clarify the situation for you.

Suppose you are researching ntdll.dll. Let it be LdrLoadDll function. Previously you need only do Ctrl+D, bpx LdrLoadDll and that's it and that's all.

Now you have to go to page LdrLoadDll write down PHYSICAL address and put CC over there MANUALLY! Isn't it a pain in the ass?

hobgoblin is correct - you get the symbols by using the symbol retriever, - get the symbols for ntoskrnl.exe

Then, add the symbol file to the list of symbols to be loaded at boot time, by using the nice DS2.7 settings dialog box. GO TO Start->Programs->Compuware"""->SoftICE->Settings. There will be an option for symbols. Add the symbol file you just downloaded to the list box.

Then, go to "Advanced", and add an NTSYMBOLS=ON string. Done.

Reboot.

I've had to do this with each DS release, AND if you apply a service pack to your WIN you'll have to get a new symbol file!

It aint rocket science !!

-Lunar

Originally posted by volodya
Satyric0n

Let me clarify the situation for you.

Suppose you are researching ntdll.dll. Let it be LdrLoadDll function. Previously you need only do Ctrl+D, bpx LdrLoadDll and that's it and that's all.

Now you have to go to page LdrLoadDll write down PHYSICAL address and put CC over there MANUALLY! Isn't it a pain in the ass?

Not really.. Just write an app that you know will call LdrLoadDll (either some framework function will call it or you can call it yourself), run that app, ATTACH to that app, and set the bpx.

So, unless you need to set a break on that function when any process in the system calls it (in which case, just hook the API call and set a breakpoint in the hook function), I don't see what's so bad about just using ATTACH...

Or maybe I'm still missing the point?

EDIT: Are you saying that you can set the bpx but it doesn't break correctly (this is what I assumed you meant previously), or that you can't even set the bpx at all? If you can't even set the bpx (by name), you just need to go to the SoftICE Initialization->Exports tab and put ntdll.dll (for your LdrLoadDll example) in the list and reboot. (I put ntdll, kernel32, user32, gdi32, etc, in this list, for a total of about 15 files).

I have just tried what hobgoblin and Lunar_Dust suggested, using Symbol Retriever to get the ntoskrnl.exe symbols and loading them upon boot. I see no difference whatsoever to the way things worked previously for me; you still have to set the appropriate address context before setting a breakpoint, either using ADDR or ATTACH (preferred, and very easy for all you naysayers, since you only have to do this once per process name).

This is the way I have SoftICE set up, and it seems to be working fine (assuming you don't consider the fact that you have to set your breakpoints in the appropriate address context to be a problem, as Squidge and I don't): On the SoftICE Initialization->Exports tab, I simply added the following files in the list:

advapi32.dll
comctl32.dll
comdlg32.dll
gdi32.dll
hal.dll
kernel32.dll
msvcrt.dll
ntdll.dll
ntoskrnl.exe
ole32.dll
shell32.dll
user32.dll
version.dll

And then also some other files that are specific to my machine/configuration.

Again, loading the symbols for ntoskrnl.exe made no difference whatsoever on my machine; everything worked just the same as if I hadn't loaded those symbols.

I realize now that I have always set my exports before using SoftICE, and I have never loaded the symbol for ntoskrnl.exe before. So the fact that loading the symbol for ntoskrnl.exe now made no difference at all makes me wonder if doing that is unnecessary if you just set your exports as I described?

Satyric0n I have just tried what hobgoblin and Lunar_Dust suggested, using Symbol Retriever to get the ntoskrnl.exe symbols and loading them upon boot. I see no difference whatsoever to the way things worked previously for me; you still have to set the appropriate address context before setting a breakpoint, either using ADDR or ATTACH (preferred, and very easy for all you naysayers, since you only have to do this once per process name).

I've tried retriever on DS30Beta2 & Windows Server 2003 VLK En.
No difference found.

I think , this is NOT A BUG of SI.

Maybe, it's because some reason of ths OS & LDT & GDT etc.
Maybe, using SI on Windows NT/2K/XP/2003, we must use ADDR/ATTACH cmd.
Maybe, on Windows NT/2K/XP/2003, we can not set a bpx, break any process who hit it.

I'll study the manual of DS and something related.

I have a problem still.

How to use the cmd HWND & BMSG?

When using DS2.7 under Windows 98, I always use the cmd like this:

-----------------------------------------------------------------------------
PROC SomeProc // get the PID and TIDs of its sub-thread
THREAD thePID //get the TIDs of it
HWND aTIDofIT // get a list of the HWND of the thread

BMSG aHWNDofIT WM_COMMAND if......
-----------------------------------------------------------------------------
but now, using DS3.0 under Windows 2003.

the HWND cmd CAN NOT get the HWNDs of a Process/Thread.
so BMSG CAN NOT use.

I've tried to use Spy++ to get the HWND of some window. then use BMSG cmd with this HWND. it said: Invalid window handle.

I've also tried to use a test program wrote by myself which tell me the HWND returned by its CreateWindowExA and then I use the HWND cmd with the handle it tell me, it still said: Invalid window handle. Then, I use attach/addr, use HWND. it still said:Invalid window handle.
Sigh!!!

I assure you that DS2.7 works fine and correclty on both WIndows 2000 and Windows XP concerning BPX. Like I've said before you have to use SYmbol retriever for your particular ntoskrnl.exe, and of course add the DLL's you are interested in, in the exports dialog of SoftICE (as well as ntoskrnl.exe itself too)

You can even load any DLL after boot by just using the symbol loader.

Here is something for you to try: Go into softice. Type "u messageboxa" (assuming first of course you've loaded user32.dll into either symbol loader or exports dialog at boot time). Do you see any valid code come up? If you don't have the correct ntoskrnl.exe symbol file, or it's not being loaded correctly, you won't see any code. You'll see that its supposed to be an export, but there won't be any code in the code window that looks correct at all. THIS MEANS the symbol file isnt' working and you didnt set it up right. This is how I always test my new SI installations to make sure they look correct.

As far at Bp on the HWND you can't be in idle process to use it. You have to "PROC", and then "ADDR" to some process with a window, and now you should be able to set such a breakpoint...some may not like the ADDR. I am telling u that ADDR is NICE. You could never do such a thing on win98. Using ADDR you can set BPXs in a process without having to first break into it. It's much more convenient.

Here is at least the minimum exports you need in dat file:

EXP=\SystemRoot\System32\ntoskrnl.exe
EXP=\SystemRoot\System32\ntdll.dll
EXP=\SystemRoot\System32\kernel32.dll
EXP=\SystemRoot\System32\user32.dll


-Lunar

Well, the case with DS3.0 is that doing U MessageBoxA shows the right code (and this is without loading any symbols, only exports). But regardless, bpxs are still not global to all processes; they only apply to the process whose address context is active when you actually set the bpx.

Again, I personally don't consider this to be a problem, on the contrary, I prefer this over the way it used to be. But for those who want the bpxs to be global, I do not see a way to do this any more.

Originally posted by Lunar_Dust
As far at Bp on the HWND you can't be in idle process to use it. You have to "PROC", and then "ADDR" to some process with a window, and now you should be able to set such a breakpoint...

As a reminder, note that you can use ATTACH instead of ADDR if you want. "ATTACH <process name/id>" causes an automatic "ADDR <process name/id>" every time you Ctrl+D, very convenient.

[hobgoblin]

Just my two cents....
I don't think this is a bug in Sice either. It is probably working as it should be. As Satyricon and Squidge are posting: I don't see this as a problem. On the contrary, I see this as a nice detail.

As I said, just my two cents....

hobgoblin

Not really.. Just write an app that you know will call LdrLoadDll (either some framework function will call it or you can call it yourself), run that app, ATTACH to that app, and set the bpx.

You, of course, know that ntdll.dll is AUTOMATICALLY being proected into the address context of the process before symbol loader pops up, before main, before everything. And it is not reasonable at all to create any Native API application. So I myself will try to play with Lunar_dast suggestion. Unfotirnately it seems to be the only real way...

Originally posted by volodya
You, of course, know that ntdll.dll is AUTOMATICALLY being proected into the address context of the process before symbol loader pops up, before main, before everything. And it is not reasonable at all to create any Native API application. So I myself will try to play with Lunar_dast suggestion. Unfotirnately it seems to be the only real way...

Yes, I do know that, which is why I can't figure out what your problem is. What is it that's not working? Is it that you can set the breakpoint correctly, but it never actually breaks? If that's the case, then there's something wrong with your specific configuration/machine or something, because it works great for me.

OK. I don't like your idea with Native API app - it is just not reasonable to create even a very small app for the Native API testing, especially if I don't know the parameters of the function.

So, how it worked with previous GOOD soft-ice:

you do Ctrl+D (Soft Ice pops up hell knows where) and set up bpx on shall we say LdrpProcessRelocationBlock. Noone really knows how is it possible to set up the GENERAL breakpoint on ANY process in Windows NT+ (with 9x everything is easy). So, you launch your app and everything is fine - SoftIce pops up on bpx and everything is working. Now what? You can't set uo the bpx on the address context because there is no address context (well, actually in the case of bpx it is but, obviously long before main()), you can't do your ATTACH macro which is, of course, nice but the general behaviour of Ice is so bad now that I just don't know what to do. Pity I don't have enough time to disassemble Ice itself.

Thanks for all the info guys i have played with it and addr is indeed easy so my problem is solved thanks again for all the info that you guys have given

ysco.