Following on from the thread "Clarification of breakpoint contexts"

I finally gave up trying to get Softice working on either Win2k or XP despite trying for several days and using every patch and hint in the known universe. (Yes did try the various symbol approaches, got just more & different freezes and BSODs)

I was attacking a running service with no breakpoints available via Softice (when it ran, which wasn't often) and its loader refusing to break on entry so no chance of even getting a starting BP on the app.

Fired up Visual Studio, selected Attach To Process, and voila ... what have I been missing. It worked perfectly, did everything which Softice seemed to do, did not crash once, and allowed me to reverse the app.

For generally debugging Windows apps is there any advantage to Softice at all? It seems not.

Occassionally, I have to agree....

What with guys at Compuware being unable to get more and more knowledge about the advanced versions of windows.

Ice for '98 worked great cause you could RE the entire OS...Ice for NT worked a little buggily cause you couldn't RE the OS...Ice for XP seems to work even more unreliably....Who knows about Longhorn?

Possible cause is that ICE is meant to be a DEVELOPER debugger. It means its expected you have the source...unfortunately, its used for lots other purposes.

But I think MS is gaining in the debugger arena. Though its got a lot of catching up to do (mainly due to the reputation of ICE), its getting there.

Have Phun

softice is for kernel debugging
and if you can use vsnet instead of softice you arent debugging kernel code

an alternative for kerneldebugging is windbg. its free, its the official microsoft way for doing kernelstuff and its very powerful

And it is not beyond M$ to screw with the competition and make something in their software that makes other company's software less functional.

Regards,

I wonder, would it really be so hard for Numega to do this:

In relation to their Softice which targets XP and Win2k;

1. Get it working, at least most of the time, which it doesn't, no matter how hard the user tries;

2. Make breakpoints work, since they are a feature of it, and they don't work most of the time either.

Surely, that can't be so hard for Numega. They managed it before and these are such basic things for a package loaded with so many esoteric powerful features.

Above all, Compuware is a commercial company. Though the tools provided are used by crackers, its primary meant to be used by developers.

Have you noticed a subtle change in their policy by promoting more and more of Visual SoftICE rather than SoftICE? What with all the fancy GUIs and stuff being more popular.

I can imagine Finance and Marketing Directors on the board demanding that something be done about the "backward" interface of SoftICE and give it a more pleasant frontal dressing. THough Visual ICE at the moment takes only remote debugging, nothing prevents its from getting to debug normal apps on single machine too.

And I imagine that they are going to develop a character GUI, much the same way as the Partition Magic Boot Disks so that the user can debug kernel in still the graphical mode.

As always, MONEY above all else. And really, I don't blame them.

Have Phun

sice has that already, to a point... You can resize the frames, click on registers, right click for menus etc. I think it would be come less user friendly if command line was replaced by 100% GUI. Once you get past the initial learning curve, it works perfectly.

To clarify: You mean that the Visual Softice only works in a two-machine scenario?

I just installed it and it looks great. But attempting to connect to localhost seems to always fail.

Surely there isn't any real reason why the front and back end of Visual Softice cannot connect? Or cannot be reversed so they will connect?

The reason is that Softice freezes the entire machine when you break into it, so that no normal application like e.g. their own GUI can execute. This would not necessarily be easy to workaround at all...

Looking at the basic capabilities of Visual Studio debugger:

Having installed the Win2k symbol pack from M$

Debug Process -> [Choose a process and attach to it, break it]

Knowing that the program calls Kernel32::ShowWindow

Set breakpoint on Kernel32::ShowWindow

(You may, or may not, see an address light up in the Breakpoints window, and clicking the breakpoint->Properties may, or may not say the debugger recognizes the symbol)

Press F5

Cause your debugged app to show window (Notepad -> About Menu as an example) and ....

no break.

Wonder why 1. Sometimes the breakpoint finds an address and not other times and 2. It doesn't break.

Since this is not a kernel debugger, I wonder if it's possible to break on windows msgs by breaking an API call somewhere conditional upon the message being called?

Sorry to have to resort to such a crude tool as VS debugger, but SoftIce really isn't playing ball with XP and I (we) need something we can fire up and debug on-the-spot as we need it. Softice seems to be falling out of fashion in that role rather rapidly.

Did try windbg, good debugger, didn't seem to be as friendly as Softice or VS debugger though

so what exactly do you want out of your debugger?

do you want to debug something for which you have source code or not?
do you want to debug the kernel or user applications?

The answer to these 2 questions will guide you in choosing the right tool for the right task.
(ollydbg, ms vs debugger, softice, windbg/livekd, ...)

I absolutely detest windbg... I use it for analyzing crashdumps, and hate every minute of it.

Windows applications without source code. With the ability to breakpoint on calls to Windows APIs and (occasionally, if possible) to break on windows msgs.

What really goes on beyond the entry to an API function isn't of great concern. The target is the windows application .exe not the API.

I have used Softice in Win9x for years and found it a great tool for the above purpose. (The only thing it doesn't do which would be nice is highlighing the contents of referenced strings when viewing disassembly. W32DASM seems to manage that task for a dead listing but having to dead-list before going to work on a prog isn't ideal + W32 doesn't handle string references correctly under XP anyway.)

Ideally I would continue to use Softice however as outlined previously it has technically broken on Windows XP and the 2k version is so bug-riddled I have never been able to get it working properly on anything newer than NT4.

Visual Studio debugger was doing a decent job until I tried to set breakpoints on windows API calls when they wouldn't fire. Softice used to do this successfully on 9x. bpx ShowWindow, etc.

I don't understand the definition of Kernel debugging or at what point in the call stack there is a transition between Kernel and user-mode code. I have no need to trace beyond the code within an .exe so I guess the higher-level debuggers will be OK. However the ability to breakpoint on an API entry point is critical to any kind of reversing.

after compuware bought numega, all of the smart people working at numega left. many went to microsoft and wintellect. thus, softice now sucks. get used to windbg, since that's where the future is.

What version of VS you are using, VS 6 or VS .NET (2002, 2003), and what your OS ?

What's cool about Windbg is that you can write your own dll debugger extensions using the WINDBG_EXTENSION_APIS. What's even cooler is that this feature of Windbg is what the Softice debugger KDextensions are based on, using many of the same API's. Therefore you can actually use Windbg to initially develop the framework for Softice extensions, and believe me this saves on BSOD's. So add LiveKD and the dump check in there and Windbg ain't all that bad (even if it is MS

Dear kayaker,
Greets

if by using LiveKd by sysinternals are we able to single step inside
int 2e (ntdll.dll syscalls) int 2b (user32.dll GetDc+0x3a) etc
and is it possible using a single machine setup (not two machines i dont have two machines) well sice may be able i dunno because i dont use sice and dont prefer to use it

btw when ever i run livekd it seems it opens up -z blah\**\\.\.dmp as its commandline
and scrolling up in dos window seems to be a big problem (nothing is visible above the window height)
so if i use livekd -w ir sure opens up windbg with kd > prompt
buti f use ctrl+i and reload or just use .load "path"
it seems the kd prompt just goes off and windbg is turned into plain user mode debugger (for which i use ollydbg and it works absolutely terrific for my needs)

since you comment upon windbg and livekd i post this up in expectation that you would be able to provide some pointers on using
windbg in concurrence with livekd

preferably a small tut with a simple crackme debugged with windbg and livekd hope i am not expecting too much

thanks and regards

ps a search on livekd in this board would turn up just three or four vague posts on livekd and windbg same scenerio in google

if you downloaded livekd, there is a readme file that explains pretty much
everything nicely.

Dear homersux,
thanks for answering
i think sysinternals probably changed livekd.zip contents between your downloaded version and my downloaded version
if it is not a problem for you and if the board rules permit i request you to
upload the readme which nicely explains things about livekd usage
thanks and regards

First download and install the Debugging Tools for Windows
package from Microsoft's web site:

hxxp://www.microsoft.com/whdc/ddk/debugging/

If you install the tools to their default directory of
\Program Files\Microsoft\Debugging Tools for Windows, you
can run LiveKd from any directory. If you haven't installed
symbols for the system on which you run LiveKd, LiveKd will
ask if you want it to automatically configure the system to
use Microsoft's symbol server (see the Debugging Tools for
Windows documentation for information on symbol files and the Microsoft symbol server).

It seems you are asking how to use livekd, well livekd is nothing
but a tool to generate a snapshot of the live machine. The real beef
is inside windbg. Remember 'help' and 'ln' are your friends.

Hi

Sorry, I don't have a LiveKD tutorial + crackme up my sleeve right at the moment, but I'd happily endorse such a Mini-project

LiveKD may not come with a manual, but it does come with a readme which states:
"LiveKd, a utility I wrote for the CD included with Inside Windows 2000, 3rd Edition, is now freely available. "

Which means... where would the best information come from?

Want more? Using good Search parameters on the net should give several examples as well. "copy and paste" code would probably have these search terms in common:
kd> livekd

Kayaker

Dear kayaker,
Thanks for a Sensible answer,
hope you grab some time from some vortex and do start a project that
works with windbg and livekd and on ways to get it debug inside syscalls
using single machine
btw Livekd is free but is the book free too (sorry i did not search but just posed this question after i read your answer)
and yes i will try to find code snippets in google with kd > as search terms
thanks and Regards

Dear Homersux,
thanks for your answer too,
but i have a niggling feeling that you havent either read my post or saw windbg and live kd and dismissed it as bah some bloody noob with a bloddy useless question to endorse my theory i quote below some parts of my earlier posts

if i read a post with such a sentance i would assume that the poster has
windbg and has installed it in the dir where ever it is supposed to be

with this i would assume that the poster has successfully run livekd and is trying to ask a question with which he has a problem

with this sentance i would assume he atleast knows some of the b***s*** which he is talking about

but probably my usage of english is very very bad i assume now because it did not convey what i wanted to convey and i still get a RTFM reply from an experienced guy like you

anyway thank you once again for answering
i hope i could improve my english a little better
regards

blabberer, thanks for pointing out those important notes, hehe. Personally
I don't use livekd that often, it is only when i need it for a kernel mode
problem, i.e. driver, kernel apis etc. Because livekd only captures a snapshot of the live machine, it's only useful to diagnose a static problem. Softice
is more useful when it comes to a dynamic problem. However, softice is
not as stable as kd, the stability and level of detail goes like this kd > windbg > sice. But sice is still the most powerful in a knowedgable hand.

the book kayaker mentioned does not contain any good kd tips, only thing I found that contains useful tips is a book about debugging windows kernel coredumps. But kd (or windbg) has a nice builtin help command that pretty much explains all the commands nicely. How to combine these commands and craft powerful results require experiment and experience. And if you have some specific question or kd related issues, let us know.

best regards

Edit: I strongly encourage everyone to use Ollydbg as their ring3 debugger, this thing coupled with ollyscript is the most powerful ring3 win32 debugger I've ever seen. However, as the 64bit stuff approaching fast, I hope Ollydbg can catch up too.

it's really (kd == windbg) > sice, since kd and windbg use the same engine

same engine, but kd is console and windbg is gui, and we all know how buggy win32 messsage queue is.

Dear homersux,
well i would like to thank you for clarifying my doubts
anyway i was intereseted to know if i can do some live single stepping inside syscalls
with a single machine

not getting some static !EPROCESS !threads !psloadedmodulelist !teb ,!peb
i wanted to know if i could single step inside

lie old debug for dos



well from your description it seems it will not be possible
correct me if my assumption is wrong
thanks and regards

If you have windows xp or 2003, I think you can do live debugging with windbg directly. Actually at this point, I am not quite sure about my statement about livekd creating snapshot of live system, you may be able to do realtime debugging as well. I got the statement from the 'windows 200 kernel debugging' book but it seems controdict with livekd readme:

LiveKd
------
LiveKd, a utility I wrote for the CD included with Inside Windows
2000, 3rd Edition, is now freely available. LiveKd allows you
to run the Kd and Windbg Microsoft kernel debuggers, which
are part of the Debugging Tools for Windows package, locally
on a live system. While the latest versions of Windbg and Kd
have a similar capability on Windows XP and Server 2003,
LiveKd works on NT 4 through Server 2003 and enables more
functionality, such as viewing thread stacks with the
!thread command, than debugger's own live kernel debugging
facility.