one of first projects ever ... (refer to readme file) ...
Posted on 2002-03-25 07:47:54 by Donnerwolf
Win NT 4.0 WS SP4

GPF - Memory access violation.
Posted on 2002-03-25 15:06:19 by The Svin
win 2K SP2
AMD K6II 450

correctly reports it as 451, no crashing.
Posted on 2002-03-25 15:36:23 by Hiroshimator
@Svin: runs fine for me on win98 and win2k pro :confused: don't know why it doesn't work for you
Posted on 2002-03-26 13:56:21 by Donnerwolf
Svin, it would probably be helpful if you could give the EIP of the GPF :)
Posted on 2002-03-26 14:02:02 by f0dder
why it doesn't work for you

It doesn't work for NT WS 4.0 , not for me.
Posted on 2002-03-26 14:31:24 by The Svin
800mhz AMD Athlon, WinXP Pro (again :( )
Posted on 2002-03-26 14:40:52 by bazik

Svin, it would probably be helpful if you could give the EIP of the GPF :)


No problem, Sir.


Exeption in process:
Process.: (pid=39)
Time: 3/27/2002 @ 2:23:58.400
Number: c0000005 (access violation)


*----> Tasks <----*
Pid Name
0 Idle.exe
2 System.exe
20 smss.exe
30 CSRSS.exe
34 WINLOGON.exe
40 SERVICES.exe
43 LSASS.exe
72 SPOOLSS.exe
79 RPCSS.exe
82 NDDEAGNT.exe
93 tcpsvcs.exe
97 TAPISRV.exe
105 RASMAN.exe
111 PSTORES.exe
114 EXPLORER.exe
121 esserver.exe
127 sens.exe
149 systray.exe
153 LOADWC.exe
155 internat.exe
89 MSOFFICE.exe
151 EXPLORER.exe
170 Far.exe
39 cpuspeed.exe
57 DRWTSN32.exe
0 _Total.exe

(00400000 - 00400000)
(77f60000 - 77fbd000) dll\ntdll.dbg
(77f00000 - 77f5f000) dll\kernel32.dbg
(77e70000 - 77ec4000) dll\user32.dbg
(77ed0000 - 77efc000) dll\gdi32.dbg
(77dc0000 - 77dff000) dll\advapi32.dbg
(77e10000 - 77e67000) dll\rpcrt4.dbg
(766d0000 - 766d6000) dll\indicdll.dbg

Memory dump for thread 0xae

eax=002c01ed ebx=002c01ed ecx=00000113 edx=00002c01 esi=00007fe8 edi=00000113
eip=0012ffac esp=0012ff44 ebp=00000000 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000202


function: <nosymbols>
0012ff97 0008 add [eax],cl ds:002c01ed=d1
0012ff99 0001 add [ecx],al ds:00000113=??
0012ff9b 0010 add [eax],dl ds:002c01ed=d1
0012ff9d 0000 add [eax],al ds:002c01ed=d1
0012ff9f 0000 add [eax],al ds:002c01ed=d1
0012ffa1 0000 add [eax],al ds:002c01ed=d1
0012ffa3 0000 add [eax],al ds:002c01ed=d1
0012ffa5 304000 xor [eax],al ds:0131ebf3=??
0012ffa8 0100 add [eax],eax ds:002c01ed=410202d1
0012ffaa 0100 add [eax],eax ds:002c01ed=410202d1
error-> 0012ffac 0000 add [eax],al ds:002c01ed=d1
0012ffae ed in eax,dx
0012ffaf 771d ja 0012ffce
0012ffb1 104000 adc [eax],al ds:0131ebf3=??
0012ffb4 0000 add [eax],al ds:002c01ed=d1
0012ffb6 40 inc eax
0012ffb7 0000 add [eax],al ds:002c01ed=d1
0012ffb9 0000 add [eax],al ds:002c01ed=d1
0012ffbb 0000 add [eax],al ds:002c01ed=d1
0012ffbd 0000 add [eax],al ds:002c01ed=d1
0012ffbf 0001 add [ecx],al ds:00000113=??
0012ffc1 0000 add [eax],al ds:002c01ed=d1

*----> Stack back trace <----*

FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
00000000 00000000 00000000 00000000 00000000 00000000 <nosymbols>

*----> Stack copy <----*
0012ff44 28 51 40 00 3a 20 e7 77 - 60 ff 12 00 01 00 00 00 (Q@.: .w`.......
0012ff54 f9 12 40 00 60 ff 12 00 - 94 01 46 00 00 00 00 00 ..@.`.....F.....
0012ff64 13 01 00 00 e8 7f 00 00 - 41 11 40 00 ed 01 2c 00 ........A.@...,.
0012ff74 d5 00 00 00 dc 00 00 00 - 30 00 00 00 03 00 00 00 ........0.......
0012ff84 02 13 40 00 00 00 00 00 - 00 00 00 00 00 00 40 00 ..@...........@.
0012ff94 01 00 01 00 08 00 01 00 - 10 00 00 00 00 00 00 00 ................
0012ffa4 00 30 40 00 01 00 01 00 - 00 00 ed 77 1d 10 40 00 .0@........w..@.
0012ffb4 00 00 40 00 00 00 00 00 - 00 00 00 00 01 00 00 00 ..@.............
0012ffc4 3c ba f1 77 bc e4 29 01 - 73 40 c4 77 00 f0 fd 7f <..w..).s@.w....
0012ffd4 05 00 00 c0 c8 ff 12 00 - 8c fd 12 00 ff ff ff ff ................
0012ffe4 74 b8 f3 77 48 d2 f3 77 - 00 00 00 00 00 00 00 00 t..wH..w........
0012fff4 00 00 00 00 00 50 40 00 - 00 00 00 00 00 00 00 00 .....P@.........
00130004 b0 5a fa 77 e8 55 fa 77 - 98 5a fa 77 00 00 00 00 .Z.w.U.w.Z.w....
00130014 00 00 00 00 00 00 00 00 - 00 00 00 00 40 00 13 00 ............@...
00130024 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
00130034 00 00 00 00 00 00 00 00 - 00 00 00 00 60 00 13 00 ............`...
00130044 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
00130054 00 00 00 00 00 00 00 00 - 00 00 00 00 80 00 13 00 ................
00130064 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 ................
00130074 00 00 00 00 00 00 00 00 - 00 00 00 00 a0 00 13 00 ................
Posted on 2002-03-26 15:38:41 by The Svin
Hm, might be a register preservation problem? Anyway, try this
version, I removed all the fancy window stuff and moved code
around a bit...
Posted on 2002-03-26 16:58:59 by f0dder
Hm, might be a register preservation problem?


Of course, it is. And it's only matter for Win callback procs.
He uses ebx in timing routing but doesn't preserve it in WndProc
(wich is callback)
But after 100 times talking about I gave myself a word don't explain it anymore (tyred), just report bugs.
Posted on 2002-03-26 17:12:18 by The Svin
Interesting it doesn't cause a problem on win2k though, it usually
bitches when registers aren't preserved :).

I guess I need to do this:
Posted on 2002-03-26 17:26:17 by f0dder

Interesting it doesn't cause a problem on win2k though

It has simple explonation.
ebx esi edi register preservation is matter only for Win callback procs,
for the rest case it's optional (upto programmer).
And again it's almost only about NT and partionally about W2K.
The key is just understand Why it is issue. I explained it more then
100 times already.
1. First people need to understand that when window created it is handled
by system not by program that create it, system just allows to "take a part"
in handling process by specifying WndProc offset.
System do all job and from time to time calls WndProc after WndProc rets it
rets to system code. For system WndProc is kinda as API for our proc, it's called and
returns always to system.
2. Dave Cutler team wich write kernel (almost unchanged upto present time)
for NT and Win32 API for NT (many of wich still remains unchanged) tried to make
the core more optimal wrote code wich rely on ebx esi edi unchanged.
They always preserved\restore esi ebx edi in their kernel and API callback return and
assumed that all code written for Win32 would do the same thing.

Now let say code wich call WndProc has some value in ebx and
use it for addressing jump and assumes that it will remain the value after WndProc returns control to calling code, now WndProc changed it and after return calling code jusmping to wrong place
(for example to some data section instead of some label in code)
or using ebx (wich it assumes is the same but actually was changed) it tries to read some data from wrong place (for example not data at all but bytes from code section) it is where GPF comes
in 99% asm progs represented in this board.
In new SP for NT and in W2K some API were updated and changed, so
the author of cpuspeed and people used it in W2K were just lucky that
the prog didn't get to API code wich rely on ebx, they just being lucky
for a moment. Add some more API calls in the prog and chance that it
could crash on W2K will grow.
Posted on 2002-03-26 18:01:53 by The Svin
nice work.. very accurate. tested on win2k sp2.
Posted on 2002-03-26 20:43:23 by smurf
Tested OK on WindowsXP, Windows2k Datacenter Server
and WindowsME!
Posted on 2002-03-26 21:01:03 by buliaNaza
Dead on here with Win98SE, Win2K, and XP.

Outstanding Donnerwolf.
Posted on 2002-03-27 15:48:33 by alpha


ebx esi edi register preservation is matter only for Win callback procs,
for the rest case it's optional (upto programmer).


True if you are calling a routine from assembly.

But if the routine is to be called from C++ or another language, then register preservation is a must.
Posted on 2002-03-28 10:05:54 by dxantos