I used this, and you had that kind of power over the machine only in the low-end architectures, Z80, 6502 and on the enterprise, on IBM mainframes, to breakpoint and stop and look at what the processors was doing. Of course, you still can do the same thing on mainframes, but we are forgetting that in the end, on our X64 machines, that we are all running machine code.
SoftICE
21–30 of 85 posts
Re: SoftICE
#22I used SoftICE to debug a multitasking IVR application I'd written in C/C++ with a stack-switching kernel on top of MS-DOS :) Great project, but it would crash once or twice a day on both the test machines we had. Couldn't figure out why. Went through the code with a fine-tooth comb, still at a total loss.
Enter Soft-ICE. Within a week I found that Soft ICE wouldn't interrupt in the hung state. That started making us suspicious that it might not be just our code.
What do you know -- both test machines (though otherwise completely different) had the same cheap $5 ripoff network card. These were causing the crashes.
Replaced those and the software worked perfectly -- ran 24/7 for 3 years without a hitch. The one time it did stop, was the NetWare stack crashing underneath.
So that's my SoftICE story :)
Re: SoftICE
#23There is a similar approach for a modern age - use the hypervisor for the debugger agent. The application called HDBG[1]. It was never production-ready though, so not so famous. Another similar application is PulseDBG[2]. It's not exactly like SoftICE, but allows you to observe the execution process locally[3], which is sometimes enough. [1] http://fdbg.x86asm.net/hdbg/hdbg.html [2] https://github.com/honorarybot/Pul…
If you're running your guest using qemu, you can also attach the gdb to that VM. It's essentially the same idea.
Re: SoftICE
#24Hmm...I remember a time before "realICE".
Re: SoftICE
#25What modern debuggers/tool can do what SoftICE did? How do you debug services and device drivers modern Windows?
Re: SoftICE
#26It was the Hercules monitor support that had those amber fossils still sitting on the desks of every video card driver authors desks (and games programmers too) into the late nineties. VxD dot commands allowed you to extend and use a plethora of debug commands beyond the built in. Once Windows had working multimonitor support, that crucial aspect of Softice's utility was no longer unique.
Re: SoftICE
#27Ancient? Ughh. I remember using SoftICE to cheat in games back in the 1990’s. Wonderful software, I wish I would’ve been knowledgeable to do something more useful than making myself invincible in Mortal Kombat or giving my characters super powers in UFO: Enemy Unknown (aka: X-Com outside North America). This was a great learning tool to understand how programs actually allocate and use memory. Long before I had taken…
Yea. I take the ancient part as a personal attack!
I used SoftIce to crack some blowfish licensing scheme of a company that went under.
It was eye opening to be able to pause Windows 95 completely. That sometimes I’d be stepping through code and all of a sudden the code style, memory locations and format all changed because the OS had interrupted and was doing something like painting the mouse.
Re: SoftICE
#28I recall those lessons for script-kiddies “Crack [software name here] with SoftICE” in early 2000s.
I don’t remember any scripting or even great tutorials or anything in the softice days. If you were using softice, you were definitely a step above a script kiddie.
Re: SoftICE
#29What modern debuggers/tool can do what SoftICE did? How do you debug services and device drivers modern Windows?
IDK.
I had a problem because a company snuck their encryption scheme into their device driver. No problem with softice, today/now, it might be harder.
Re: SoftICE
#30Oh my I remember friends debugging Windows device drivers with SoftICE, that was hardcore.
I did it on my first debugging project where I had to teach myself assembly. Had no idea it was a special task! Just knew it had to get done, got “some program called soft ice” to do it, got to work.