Hiya,

I seem to be having a problem loading IceDump. The error message is the infamous "VXDLDR failed to load icedump"...
Not wanting to be too much of a lamer , I did a search of previously addressed IceDump load problems and have looked into the proposed solutions. Several of these mentioned the need for loading the kernel32.dll exports in winice.dat. I have done this, but the error remains...

Digging just a little bit deeper, I set a breakpoint on VXDLDR_LoadDevice, the call that loads the IceDump driver.

include vxdldr.inc

mov edx, [Devicename]
mov eax, [Flags]
VxDcall VXDLDR_LoadDevice
jc errorhandler

Devicename
Address of a null-terminated string specifying the filename of the VxD.

Flags
Indicates whether the device is initialized by the system or by the calling VxD. If this parameter is VXDLDR_INIT_DEVICE, the device is initialized by the system. Otherwise, this parameter should be zero, and the calling VxD should initialize the device and send the SYS_DYNAMIC_DEVICE_INIT message.

The flags parameter is the above mentioned VXDLDR_INIT_DEVICE and the Device name simply the path to icedump. The function fails with a return value of 07h, which corresponds to a VXDLDR_ERR_DEVICE_REFUSED. According to the MSDN, the meaning of this error is "Specified device operation not allowed. " Further investigations on this particular error, it's cause and solution have not turned up very much.

For whatever its worth, I should also mention that I am running Win98 SE on an AMD Athlon XP 2200 processor and the system is currently in a dual boot configuration with Win2K (Win98 is installed on the F partition and Win2K on the primary partition C). I would also like to say, that I currently have an old 300 MHZ machine with Win98 SE installed from the same Windoze copy on drive C, running the exact same version of SoftICE, and the exact same version of IceDump and it works perfectly.

...Now would be a good time to extend my complaints even further, I suppose I am also having extreme difficulties with using the bpr function on my AMD system (it works find on the old 300 MhZ). Any attempt to use *any* form of the bpr or bprw locks up my system irrecoverably when I attempt to resume execution of the target. I have concluded that winice never makes it into the int 0E page fault handler (bpr works by marking the target pages 'not present'), and locks up immediately upon any attempt to resume execution. Therefore, the an error must occur when SoftICE sets up the range breakpoint. I am attempting to examine the bprw function in winice, but have met with extreme displeasure at any attempt to trace it (breakpoints don't work, a manual int 3 breaks but causes a page fault when I try to trace...ect).

If anyone can shed some light on this or has experienced similar problems I would be eternally grateful to hear of it

Thank You,
Clandestiny

Hiya

As you know, you and I have been working on this tirelessly, LOL, since you made that fateful decision to upgrade with an AMD processor, and BPR hasn't worked on your system since. So much for porting our Backtrace buffer disassembler to DriverStudio :-[ I was playing with something tonight that might quick-step us through some of the code...

The first step might be to see if the SI breakpoint structure is being filled correctly on a BPR. You can do this by comparing between your 2 systems, this would at least be a beginning. After applying Toteu's Icedump-to-IDA inctoida.idc IDC script, winice becomes *much* more readable, and damn, even understandable, big kudos to both sides

The BPR routine begins here more or less. bUserCommand is the command you typed into the command window, i.e. BPRW Notepad T, pSkipWord is basically a parsing routine, and pAllocateBP is where we want to start.



If you double click on the aTdjf entry you'll find the starting address of the Softice breakpoint table, which you can convert to your memory addy and display in SI.
:C003B8D4 aTdjf db 'TDJF',0
Each array in the table begins with the word 'TDJF' (whatever that means), is 183h bytes long, and there are 256 of them, allowing for 256 possible breakpoints. If you display the address 100h*183h from the starting address you'll find the last of the arrays.


Now I went through and set up several breakpoint types and /screendumped them to try to determine the exact format of the structure, and while not exhaustive I can tell you that for SI4.05 it *does not* match the Softice breakpoint structure as outlined by Ralf Brown! (This was outlined in the FGJM interface in his famous Interrupt list). Even the breakpoint mode and type values seem different from what was documented for the old SI versions (was this valid in 2.x?).

I'm realizing it's useless to paste any of the screendumps or make assumptions on the correct BP structure without a lot more work, but I'll up the output I've got so far as an example, along with a few observations, plus the original Ralf Brown definitions. If you compare them closely you can start to see patterns, i.e. which byte defines a R, W or RW type BPM breakpoint etc.

Clandestiny, compare what you get with your AMD and see if it matches my BPRW Notepad T, or check it on your other system. If it looks like the BP structure is being filled correctly, then your problem lies further on. This should help reading the disassembly as well knowing what you're starting with and the significance of a line like 'cmp dword ptr [ebx], 464A4454h'

(btw, bpm rw seems to work better in SI than bpm x, if you can find a good memory addy to use that won't be called elsewhere from where you want to trace and won't cause a crash 'n burn...)

I won't bore these fine people any further, good night

Cheers,
Kayaker

I think it's user32.dll exports as well (check the manual ;-).

How about tracing the SYS_DYNAMIC_DEVICE_INIT handler code in icedump? That should tell you what and why fails...

Too much RAM maybe?

I think that old int3 based API would not let you directly specify the contents of an internal structure, so no wonder there's no match.

Before you overdo yourself, take a look at icedump.cjb.net... ;-)

Very nice. And only available within the past week as well. I ran the scripts with only minor complaints from IDA, and matched up the definitions with what I had recorded, filling in the gaps. It's interesting to see how the bp structure fields change with the different breakpoint types. This clarifies quite a bit, thanks for the heads up ;-)

Kayaker

Thanks guys



I have solved my IceDump problems... I traced the SYS_DYNAMIC_DEVICE_INIT code for the vxd as suggested. The final problem was a bit, umm... embarassing I found the problem in the GetAPIInfo function during IceDump initialization which gave me the sneaking suspicion to recheck the exports. I had previously checked that the exports were loaded in winice.dat. What I had not checked was that the path for the exports was correct... My Win98 partition is now on drive E, not C anymore! And I traced a hundred lines of VxD code to find this out !



Well, not unless 256 MB is too much... I pulled out my other 256 MB stick to try the suggesion in desparation though (total is normally 512) I don't have any DDR RAM smaller than 256 so I can't say if 256 is too much. I can hardly believe that it could be too much though! Thanks for the pointer to the IDA scripts. Since I can't trace this part of winice very well, I suppose I will start by examining the breakpoint structures between the working / non-working machines as Kayaker suggested. Any other places you could point me to look for the origin of this type of lockup on range breakpoints. I have no doubt you have a much better grasp of winice internals than this desparate newbie blindly stumbling through the bowels of winice

Kayaker, thanks for the very informative post and other info you sent me I'll be getting back to you with some more info soon. Just wanted to extend a public thanks for all of the help

Cheers,
Clandestiny

Hey, isn't that how we all really learn (by making then figuring out our mistakes ;-)?

I can't give you the reference but i have these faint memories about winice not working (well) if you had 512 MB due to some memory allocation conflict with vcache or some other similar driver.

I would definitely start reading and following the very nice winice documentation by Spath. Along with a properly prepared IDB it should be almost like reading a book ;-).

I'm sorry bro but i think i'm not really your guy. You should probably talk to folks like Spath or the icedump people or Sten&Mamaich over at reversing.net.

Properly prepared and delicately spiced, a pair of culinary delights:

http://reversing.net/tools/021/index.htm

Hello username !

Since you don't remember the reference any more, here's a little hint (http://www.woodmann.net/forum/showthread.php?threadid=804) for you.

I'm just wondering how you're remembering this "faint memories", but keep telling me that you weren't around at this time. I guess this is a bit strange, isn't it?

I haven't seen any posts from "the icedump people" on this board the last months as they don't seem to be posting here any more, right?

Darn DaikenDX :

You beat me to the punch with the reference to the "#804" post.
I certainly recall it rightly enough because I had this exact problem when I upgraded my RAM to 512 mg.

And does it really matter WHO username might be if the information provided continues to be of high quality, even if, at times, it might come with a sharp edge?

Keep this great information coming folks, there's ALWAYS more to learn.

For those of you reading along who may not have already done so, you can find a copy of +Splath's essay on "Softice Internals" here:

http://www.woodmann.net/crackz/Tutorials/Siceints.txt

It's a good one to add to everyone's library.

Regards.

Cool! I should remember to use the search engines more, doh :P.

It's easier than trying to guess it: google for 'vcache windows crash' and you'll see (that vcache itself has a problem with large amounts of RAM, not hard to figure that softice won't improve on that ;-).