Usual disclaimer...I have spent inummerable hours researching the stock softice solutions and this one is mouse-related, and a bit weird. I was actually learning Olly, and stepped back to ice for a comparison. My mouse has taken to freezing, but ice works ok via the keyboard.

History...ice (ds 4.3.2) was working fine earlier in 2007 (on XP with SP2). During the summer, I made the mistake of d/ling a bunch of micro$oft hotfixes, etc. Subsequently, got the old 'micopyonwrite' error and my mouse froze after ice boot, both in XP and in ice. Rolling back the hotfixes to mid-2006 got rid of micopyonwrite error. Mouse still freezes on ice boot. No other errors indicated.

Tried boot.ini trick with version 5.1.2600.1568 ntoskrnl.exe (renamed to old_krnl.exe). OS didn't like that, asking for hal.dll. Renamed a hal.dll from same source as ntoskrnl 1568 to old_hal.dll and used this line in boot.ini:

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft WinXP DS 3.1" /fastdetect /noguiboot /KERNEL=OLD_KRNL.EXE/HAL=OLD_HAL.DLL /NoExecute=AlwaysOff

as recommended by micro$oft. Typically, it didn't work. OS keeps asking for hal.dll.

Anyway, the mouse freeze seems to be something else...maybe new drivers added. I have added a linksys router, but I disabled it, as well as my sygate firewall with no luck. Even disabled nvidia drivers, and tried reducing video acceleration. Of course, reducing it to much kills the ice video.

In the old days, a mouse freeze usually indicated an IRQ conflict, or a memory address conflict. I'm racking my brain to think what might cause this one...or to find a way to trap it.

I have also changed my keyboard to a USB keyboard, but the kbrd works fine in ice while the mouse freezes. The mouse is a Logiteck ps/2 optical with 2 buttons and a wheel.

I realize the writing is on the wall for ice, but it's like an old friend. It's too good to be put out to pasture.

Any ideas?? Is it reasonable to assume that a mouse problem should not be related to osinfo.dat version, seeing that ice works? The window appears and disappears, and ctrl-d brings it up. I can maneuver fine with the keyboard in ice.

well, i suppose you dont have Intel Pentium processor ? :P (i had major problems with softice when i was on Pentium4 ... but when i bought a new pc with AMD inside the problems just vanished..). and if you didnt .. you should update your DS to v3.2.1 (http://www.woodmann.com/crackz/Tools/Ds321.zip)..
oh and this .. if you have an nvidia gfx card .. you shouldnt use the latest ForceWare cause they kill sice

ps: i dont think service pack is the problem ... because i've tried softice on VMware with winXP SP3 (pre-beta) installed and it worked okay

Yeah...I do...but...everything was cool till the past couple of months. The Pentium isn't an issue.

update applied a while back. I'll look into the nVidia solution. Thanks for response.

Forget about using the mouse, I have never gotten it to work since a Pentium 233 up to my current Pentium 4 (with numerous machines in between) but I haven't encountered a freezing problem... I only remember either the pointer being invisible or the buttons not working.

Just use the keyboard -- SoftICE isn't GUI based anyway.

Thanks for the input LLXX. I have thought of doing that but I have never had problems with the mouse before and kind of got used to it. Also, if I exit ice, I can't use it in XP till I reboot.

I'll keep looking for a solution, but if push comes to shove. I'll take your advice, or try the VM.

Hi WAX welcome to Ice hell.

I have gotten convinced that the failure of Sice in newer computers and newer OS updates hotfixes usually don't have "A" cause, but are a constellation of causes, a perfect storm of software and hardware incompatibilities, which windows is able to navigate, but SoftIce is not.
For isntance: HotFix installations are not perfectly reversible, the computer does not get back to the exact same state it was before. Some key files get updated and overwritten and are left that way. This could be tested by comparing virtual machines 1-before, 2-after hotfix and after 3-hotfix reversal. You will find out that state 1 != state 3.

I guess one technical answer to this problem has been the driver certfication program ongoing with Vista, if it were not for the small problem that it gives to Micro$oft unprecedented, discretionary power to dictate who can get into the market, and who cannot. . .

Going into virtual machines has been, for me, the most practical solution to this problem, allowing me to throw away and recycle any OS install that refuses to work. But by no means it mirrors your stated problem. the "Hardware" and the "drivers" inside the VM are not the same ones in your computer.
If you really wanted to pinpoint the problem, perhaps you should make a small, sandbox install of winXP in a different partition, or second HD, and do your debugging and testing there.

Ice hell...would that be near Ring 0?? :-) Thanks for useful comments, naides. I've had pretty good luck with Ice in XP. It has been very stable. Till now, my problems have been limited to a buggy version of Sygate personal firewall, and that was eliminated by upgrading it. Other than that, the only issues I've had were video problems.

I understand what you're saying about Hotfixes, and maybe I'll try a maintenance install of XP to see if I can rebuild it to the point where the Hotfixes are overrun.


Talking about Micro$oft and their big-brother-type paranoia gives me the heebies. I'm holding off on Vista till the DRM thing makes Vista so unstable that Micro$oft has to abandon it. I can't even get into Hotmail using Opera without a hassle.



I'm basically aware of the foibles of running on VMWare. BTW...Soundblaster has a nice little 'PCI 128' driver that works well with their sound cards in VM. I recently loaded Linux Fedora 7 in a VM box, and it works adequately. It's a bit slow, but I'm only using 512M RAM. I'll try a gig and see what happens. It's time to try running Ice on a VM. I'm more worried about the learning curve than anything.



good idea. I have a spare 60 gig drive I could load with XP and plug it in when required.

Continuing my own thread...I put the problem on hold till I checked out other possible problems in Windows XP. For example, I unloaded all the updates, hotfixes, etc., and SP2 itself...being very careful to cut off my internet connection while doing so. I reloaded SP2. I ran into grievous problems doing all that, but managed to get a new and stable SP2 install.

None of the above cleared up my 'no mouse' problem. Also, I back-dated my NVidia driver, so it's not that either.

I noticed something peculiar, which maybe someone can help me with. I should mention first, that I recently changed my keyboard to a USB type. It's a Logitech with the 12 separate function keys for bringing up the calculator, etc. Also, it has a Windows key. The mouse is a PS/2 mouse.

When I first start softice, the DOS window comes up, the softice screen rolls by, and the DOS window closes. After it closes, I have no mouse in XP. Here's the peculiar thing: if I ctrl-D into ice, there is no mouse at first. Once I do a single trace step (T <enter>, the mouse comes back. It only comes back in ice though, if I go back to XP, there's no mouse.

When I go into ice, the code window cursor is sitting in kbdhid.sys, just after a call at 8:B80BAF51. The call is HidP_TranslateUsageAndPagesToI8042ScanCodes. That seems to be a system function since I can't find a reference to the exact function on the net.

I was going to post some code but after a preliminary trace through ntoskrnl and several USB imports, I'm wondering if I'm on the wrong track. Softice seems to be sitting in a loop involving kdbhid.sys. It breaks in that loop at the same spot every time. I'll post the first part of the code, however, since there's a reference to 'Chattery Keyboard'. I found this note in an old DS 2.6 blurb that reads:

When using a USB keyboard with SoftICE, Windows will display the following message:

**** CHATTERY KEYBOARD : Keyboard is sending useless reports. Tell 'em to fix it.

This message is caused by the SoftICE keyboard hook code, which prevents Windows from seeing SoftICE's hotkey. This message is normal when using a USB keyboard with SoftICE, and can be ignored.

Here's the code (note reference to Chattery at 0008:B80AEF84):

_KbdHid_ReadComplete+01A1

0008:B80AEF49 E826090000 CALL _HidP_TranslateUsageAndPagesToI804
0008:B80AEF4E 8B4350 MOV EAX,[EBX+50]
0008:B80AEF51 8B4B54 MOV ECX,[EBX+54]
0008:B80AEF54 33FF XOR EDI,EDI
0008:B80AEF56 894B50 MOV [EBX+50],ECX
0008:B80AEF59 894354 MOV [EBX+54],EAX
0008:B80AEF5C 397DF8 CMP [EBP-08],EDI
0008:B80AEF5F 0F86B7000000 JBE B80AF01C
0008:B80AEF65 8B4358 MOV EAX,[EBX+58]
0008:B80AEF68 663938 CMP [EAX],DI
0008:B80AEF6B 0F8586000000 JNZ B80AEFF7
0008:B80AEF71 8B435C MOV EAX,[EBX+5C]
0008:B80AEF74 663938 CMP [EAX],DI
0008:B80AEF77 757E JNZ B80AEFF7
0008:B80AEF79 8D8688010000 LEA EAX,[ESI+0188]
0008:B80AEF7F 803800 CMP BYTE PTR [EAX],00
0008:B80AEF82 7528 JNZ B80AEFAC
0008:B80AEF84 6840ED0AB8 PUSH B80AED40 ; **** CHATTERY KEYBOARD : Keyboard is sending useless reports. Tell 'em to fix it.
0008:B80AEF89 C60001 MOV BYTE PTR [EAX],01
0008:B80AEF8C E883080000 CALL _DbgPrint ...prints Chattery message
0008:B80AEF91 834E4801 OR [ESI+48],01
0008:B80AEF95 59 POP ECX
0008:B80AEF96 56 PUSH ESI
0008:B80AEF97 E876F7FFFF CALL _KbdHid_UpdateRegistryProblemFlags
0008:B80AEF9C 8B06 MOV EAX,[ESI]
0008:B80AEF9E 57 PUSH EDI
0008:B80AEF9F 6801000580 PUSH 80050001
0008:B80AEFA4 FF7008 PUSH [EAX+08]
0008:B80AEFA7 E8F8F7FFFF CALL _KbdHid_LogError
0008:B80AEFAC 807E3500 CMP [ESI+35],00
0008:B80AEFB0 7527 JNZ B80AEFD9
0008:B80AEFB2 807D0F00 CMP [EBP+0F],00
0008:B80AEFB6 7421 JZ B80AEFD9
0008:B80AEFB8 8D8634010000 LEA EAX,[ESI+0134]
0008:B80AEFBE 50 PUSH EAX
0008:B80AEFBF 57 PUSH EDI
0008:B80AEFC0 FFB684010000 PUSH [ESI+00000184]
0008:B80AEFC6 8D8658010000 LEA EAX,[ESI+00000158]
0008:B80AEFCC FFB680010000 PUSH [ESI+00000180]
0008:B80AEFD2 50 PUSH EAX
0008:B80AEFD3 FF15ACF90AB8 CALL [KeSetTimerEx]
0008:B80AEFD9 6A18 PUSH 18
0008:B80AEFDB FF7640 PUSH [ESI+40]
0008:B80AEFDE 8D4658 LEA EAX,[ESI+58]
0008:B80AEFE1 50 PUSH EAX
0008:B80AEFE2 FF1520FA0AB8 CALL [IoReleaseRemoveLockEx]
0008:B80AEFE8 81C600010000 ADD ESI,00000100
0008:B80AEFEE 56 PUSH ESI
0008:B80AEFEF FF15A4F90AB8 CALL [KeCancelTimer]
0008:B80AEFF5 EB65 JMP B80AF05C ....jumps here

I've taken some liberties with the code to make it more readable. When I first break into ice, the cursor is sitting at:

0008:B80AEF4E 8B4350 MOV EAX,[EBX+50]

The mouse is frozen, but the minute I single step to the next instruction, the mouse works fine, in softice. I'm thinking maybe there's something else going on that I might be missing.

On the first loop, the message about the Chattery Keyboard is printed on the softice screen. On subsequent loops, it is not printed. It reads:

**** CHATTERY KEYBOARD : Keyboard is sending useless reports. Tell 'em to fix it.

Is this maybe a focus problem? When I first go into softice, the mouse is not working. After I do a single trace step, it is. Am I bringing the focus to the softice code window, and if so, how does that affect the mouse? There is a point later on when the mouse freezes again. I need to do more work to identify that point, but another trace step gets it back. I think that point comes around:

0008:B80AEFE2 FF1520FA0AB8 CALL [__imp__IoReleaseRemoveLockEx]
0008:B80AEFE8 81C600010000 ADD ESI,00000100
0008:B80AEFEE 56 PUSH ESI
0008:B80AEFEF FF15A4F90AB8 CALL [__imp__KeCancelTimer]
0008:B80AEFF5 EB65 JMP B80AF05C

The mouse is frozen at the JMP but comes back after the JMP, when I do a single trace step.

Simple things first.
Can you connect your old OS/2 Keyboard and Mouse and see how Sice behaves?

I was going to borrow a keyboard. The old one is fried...someone?? spilled something on it. Imagine!!?

The mouse is the original. Thanks for input, naides, ...I'll get back to you.

How right you were...thanks.

I borrowed a ps/2 keyboard and softice worked fine. Then, I remembered getting a USB mouse (mouth...as Sylvester would say) with the keyboard. I plugged it into a spare USB port, and softice likes that too. So, USB mouse + USB keyboard seems to work, but not PS/2 mouse + USB keyboard. I like the ps/2 mouse better, for handling, so I might try a ps/2 to USB adapter to see if the USB port will accept data from a ps/2 mouse.

Unfortunately, nothing ever goes all that well. Softice (startsi) now is hogging 70% of the cpu cycles. A rundll started app, ncpa.cpl is hogging another 20%. I looked it up and it seems to be 'My Network Places'. Go figure.

Since I reloaded SP2, I'm also getting this error in softice:

Int0E Fault in SoftICE at address B5DB1ECB offset 00096C43
Fault Code=00000001
DS=0010 ES=0023 FS=0030 GS=0000 ESI=FFFFFFFF EDI=8058AE20 ESP=B6141C24
EAX=00000001 EBX=00000000 ECX=00000000 EDX=00000001 EBP=B6141C78

FrameEBP RetEIP Syms Symbol
B6141C78 F77077AC N NTice!.text+00098B4B
WARNING: One or more symbol tables were not present. Stack backtrace through not-present tables may be incorrect!

I wont bother you about that one. It's probably a misconfiguration between the osinfo.dat file and ntoskrnl. I need to play with it.

Answering my own post again. The problem witht the symbol tables seemed to be related to the ntoskrnl version put there by the SP2 update. I inadvertantly used the 'TABLE' command to check the loaded nms files and there was an error indicated. There were asterisks beside the offending nms files, indicating a problem with the timestamps in the files.

I had trouble downloading the required ntoskrnl pdb file using symbol retriever. Don't know why exactly, but I'm sure it had something to do with the hotfixes, etc., I had installed prior to reverting to the old SP2 upgrade. The nms files I was using were from the updated hotfix/update files.

I fixed the problem by loading both ntoskrnl and ntkrnlpa into the retriever at the same time. The retriever got both the pdb files and the nms files from that download got rid of the error message. I tried many times to get ntoskrnl by itself with no luck. Maybe the ntkrnlpa was required. I also downloaded pdb files for kernel 32, ole32 and win2k, since they too were flagged by the TABLE command as being not right. Now ice is running with the mouse and indicates no errors on startup. Also, the TABLE command indicates no errors.

The acid test came thanks to Kayaker's hint for breaking in an app using symbol loader. It can be found in this thread:

http://www.woodmann.com/forum/showthread.php?t=7528&highlight=ntsetinformationthread

and uses this breakpoint:

BPX _NtSetInformationThread IF *(esp+8)==9 DO "dd esp"

Before fixing up my nms files, I couldn't even list _NtSetInformationThread using the 'exp' command in ice. After fixing them, I set up the BP as suggested by Kayaker, loaded my app in loader32, and bingo, the app broke like a charm. I single stepped the rest of the way right to the entry point of the app.

Happy to say that reports of the demise of softice have been greatly exaggerated.

Damn, I had forgotten about that trick! I gotta start using it again. I usually use my own loader, based on a dll injection technique and inserting an Int01 (with I1HERE ON) before jumping to the EP. It's more reliable than the Softice loader for breaking on EP but the Int01 interferes with IceDump, and some protections can detect the extra running dll thread.

That BPX would be a good one to put into a persistent macro to be called just before starting the target app..


Glad you got the problem fixed and thanks for posting the solution.

Hey Kayaker...there 'seems' to be an even easier method. I thought I'd seen it on RCE but the closest I could come to it was:

http://www.woodmann.com/forum/showthread.php?t=5933&highlight=baseprocessstart

Even at that, pLayAr 'suggested' K32!BaseProcessStart. He obviously knew about it.

Making sure the context is in K32, using 'Table kernel32', assuming the K32 nms file is loaded, a simple 'BPX baseprocessstart', will land you just about right on the EP of the app.



With the BP set, ice breaks in K32!baseprocessstart when the app is loaded by loader32. A quick look down the code reveals the following:

7C816D46 Call NTSetInformationThread ...your call
7C816D4C Call [EBP+8] ...to EP of app

The [ebp+8] points right at the entry address of the app. Stepping over the other calls and tracing in there one step puts you right at the entry code of the app.

Don't know if this works in general, but don't see why not.

yes setting a bp on that call always works thats where the executable's main is called from kernel32.dll

to reach here set a bp NtContinue and when its hit find the context->Eip the context will always hold BaseProcessStartThunk()
it pushes 2 constants and will jmp unconditionally to BaseProcessStart()

here is my lille contribution to sice manual loader



and use loader to set int3 at the ep of app or tls callback depending on protector, so far the simplest way to load app in sice

Hey deroko...how's it goin'. Thanks for dropping by. You're a guy who knows a lot about sice, maybe you could help me with something.

I'm getting a lot of thread manips (manipulations) with this app, and I get a lot of calls using mutexes, semaphores and events. In conjunction with those calls, I sometimes get myself tangled up in ring 0 code, tracing out calls to msgwaitforsingleobject, or just waitforsingleobject. With those two calls, I often find that jumping over them sets off an event, like a window loading, or something, so I try to trace into the call to see what's happening.

Part of my problem has been about having drivers loaded from firewalls or nic drivers, and they tend to interfere with tracing the code through ring 0 portion of the calls. Do you have any tips, similar to your tip for stopping sice, on how to handle func like waitforsingleobject, in sice?

I'm saying hello to deroko here 'cause he helped me before. Anyone can feel free to answer though.

Hi Waxford,

Just a thought, other than completely disabling the processes you find interfering, maybe you can raise the priority of the process you're tracing to high or realtime using Process Explorer (right click / Set Priority). And/or lower the priority of processes you see interfering with your tracing the same way if possible.

When I was playing around with the breakpoints on KiSwapContext that we discussed in that other thread, I was doing it under VMWare and found that vmware related threads were the most numerous and it seemed to take "forever" for the thread I created using CreateThread to start running. Even a MessageBox within that thread would relenquish control back to the thread dispatcher and vmware would once again get the timeslices before my thread would be returned to and the MsgBox displayed. The conditional IF on the bpx SwapContext was necessary to avoid dozens of breakpoints not related to my thread. So I think I understand the annoyance you're facing.

Screwing around with thread priorities might cause some problems, and I'm not sure how it would affect the outcome of tracing the Wait functions, but hey, it's worth a try and we might as well let you test it for crash and burnability first

A good resource for understanding (or being confused by) thread scheduling is the

Windows Operating System Internals Curriculum Resource Kit (CRK)
http://www.academicresourcecenter.net/curriculum/pfv.aspx?ID=6191

Check out UnitOS4, maybe you can find some clues there.

Kayaker

Thanks Kayaker. The main offenders are the firewall and the router. Occasionally I get caught with a virtual CD driver. I have been shutting those off, which helps, but processes like the USB drivers, remote call procedure, and the nosey WMI interface can get annoying. I guess that's the price of multitasking, but it bugs me that processes interfere that don't need to interfere.

The main problem I'm having is understanding functions like waitforsingleobject. From what I understand, the calling thread uses that function to wait for another thread to finish its business before proceeding. I assume the other thread is using a resource the calling thread needs. Or, maybe the calling thread needs that process to take care of certain things before it can proceed.

I obviously don't understand enough about threads yet. You mentioned the swapcontext function, and I'm wondering if it's possible for me to be in one thread and trace through to another. It's obviously not only possible, it happens. It would seem that if waitforsingleobject is waiting for another thread, or process, I should be in that thread or process to see what's going on. How do I get there? Is it possible via the swapcontext kernel function you mentioned?

The other thing I'm bothered about is the significance of mutexes, semaphores, etc. I understand basically their function: to get exclusive control of a resource for a thread. What I don't yet understand is how important they are as far as tracing is concerned. A mutex, for example, seems to be involved just as a device to give one thread exclusive focus, but does it play any other function? In other words, is it worth tracing into in the sense that it leads into useful code, or is it better to simply jump over it?

Like you, I have traced through many kernel calls to waitforsingleobject, only to have it leads to a system thread. I've seen the thread 12 calls deep on the stack with calls to ntdll, ntoskrnl, etc. Sometimes I can F12 out of those calls, but other times I trigger something that sets off the app and bypasses where I need to go.

The only real way is to trace and take notes. Just as certain landmarks are available in k32, like baseprocessstart, I'm sure there are ways to jump over uninteresting code in waitforsingleobject. I was getting lazy and looking for a cute way out.

BTW....if several threads are running in one process, can those threads be running code in the same process? Maybe that's where I'm messing up. I have the notion that a thread needs to reference code in another process, like a loaded dll. The app I'm working on has at least a dozen dlls it uses for different functions. However, the IPC stuff seems to be operating between code snippets in the same process. I should say, it might be operating between code in two instances of the same app.

When I look under 'proc' in sice, I see two instances of the same app running, and they have the same name. If I look at them in process explorer, the two processes have three threads each.

Sorry...I'm getting my threads mixed up. Changing context, to the threads on this board, I made reference to IPC, which of course is in another thread I have running. Please excuse my addled brain.

With reference to your URL above, there sure is a lot of good info there. I brought back a quote from part of it, that tends to underline the confusion I am experiencing with respect to what I call unnecessary verbiage. It goes as follows:

***Scheduling is a fundamental operating system function. Almost all computer resources are scheduled before use. The CPU is, of course, one of the primary computer resources. Thus, its scheduling is central to operating system design.***

The CPU is a primary resource???? It's scheduling is central to operating system design??? You don't schedule a processor, you send it an interrupt. Microsoft has even abstracted that with it IRQL's, a software abstraction of the real thing.

Programmers have got to come back to Earth!! They are abstracting everything to death. A CPU is a central processing unit...it is hardware...it is real. It operates on real registers and memory spaces that hold electrical charges to represent the abstractions we call 1's and 0's. Maybe somebody should show one to the author. I'm sure he has it abstracted as virtual registers that share the abstract object spaces and other figments of the human mind...like time.

No, no, no...the CPU does not give a gobsmack about being scheduled...it is the scheduler. Even the kernel has to politely ask it to interrupt what it is doing to get service. The CPU is an entity unto itself: ir runs off a crystal clock and goes about it's business whether we in the outside world need service or not. The only way we can stop it is to shut off the power. The code we feed it works only because the CPU already knows how to interpret it and schedule it's execution.

It pages RAM to disk, for example, without asking us if it's OK. I'm sure Bill Gates, with his monstrous ego, thinks his app is running the show, but the truth is that Intel is actually pulling the strings. For that, I am eternally thankful. Without the processor and it's independant mandate, reversing would be incredibly difficult, if not impossible.

A CPU is no more a system resource than my brain is a resource for my body. I'm an electronics technician, and I don't deal in abstraction, other than the theory of electrons, etc. That's why it's difficult being a technician, having to think in abstractions then deal with the real parts that make up a circuit or system. As an electrician, if you get too abstracted with a voltage like 347 volts, you get a thumb burned off, or forfeit your life. That keeps you reality bound.

Maybe I'm wrong, or just plain stubborn, but I refuse to buy into the modern programming abstraction of real things. It seems to be a trait of smarmy, Yuppies who think it's cute to talk gobbeldy-gook [(noun) : a crazy jumble of words as in a fake language or gibberish..]. When I finally got the chance to read Bjorne Stroustrup's interpretation of C++, it was refreshing to hear the author of the language describe it in down-to-earth terms. Stroustrup doesn't mince words, unlike many of the other C++ authors who insist on talking jargon.

When I read about mutexes and waitingforsingleobjects, I spend a lot of time trying to visualize what is actually going on with respect to the code. Modern languages have made that very difficult seeing that the explanations of those functions are bound to abstractions. When I'm tracing through kernel code, I'm not seeing objects and resources, I'm seeing code. I try to understand where I'm at with reference to the instructions. From that perspective, I find OOP programmers annoying due to the ridiculous abstractions they have developed.

Sorry for the rant.