<Same thing here, no problem killing the timer process on Win2K. One small point though, I added the code <to a test dialog and after a successful TerminateProcess the callback continued on to a C0000005 <access violation,

<77E189CE  test        byte ptr ,0C0h

<A simple 'uses ebx' in KillProcess Proc solved the problem.  Perhaps in your situation not preserving the <register didn't cause a crash but did cause some kind of hang/delay.


I would like to learn about how to debug my programs. Is there a tutorial that show how to do a test dialog?

I put in a uses ebx inside the KillProcess, but got a compiler error.

In the old days, all I had to do was put in some int 3s and step through it.


Thanks.

Posted on 2006-02-17 16:58:52 by skywalker
Well put an int 3 in it and set up Olly Debug (http://www.ollydbg.de/) as your JIT debugger :)
Posted on 2006-02-17 17:55:54 by JimmyClif
I put in a uses ebx inside the KillProcess, but got a compiler error.


Hi skywalker,

I see this is from that other post.  I should have specified how to use "uses" to preserve a register. You don't add it after the locals but in the proc prototype itself.  And yes this is the same as using push/pop of the registers in the procedure prologue/epilogue.

For example to preserve these 3 registers write it as
KillProcess Proc uses ebx ecx edx
Posted on 2006-02-17 23:59:50 by Kayaker
The best way for me for SOURCE LEVEL DEBUGGING is windbg.exe. An optional way is Visual studio. There is nothing wrong with olly dbg, but it's capability is far away from those 2.
Posted on 2006-02-18 01:43:56 by shaka_zulu

I put in a uses ebx inside the KillProcess, but got a compiler error.


Hi skywalker,

I see this is from that other post.  I should have specified how to use "uses" to preserve a register. You don't add it after the locals but in the proc prototype itself.  And yes this is the same as using push/pop of the registers in the procedure prologue/epilogue.

For example to preserve these 3 registers write it as
KillProcess Proc uses ebx ecx edx


This assembles OK, or is it supposed to go before .data.

Thanks.

KillProcess Proc uses ebx ecx edx

KillProcess  Proc
      ;uses ebx
      Local  @stProcess:PROCESSENTRY32
      Local  @hSnapShot
Posted on 2006-02-18 05:59:38 by skywalker

The best way for me for SOURCE LEVEL DEBUGGING is windbg.exe. An optional way is Visual studio. There is nothing wrong with olly dbg, but it's capability is far away from those 2.


I have windbg installed. I think I need to do this first, but not sure how to.

You must install the symbol files for the user-mode process that is being debugged. If this is an application you have written, it should be built with full symbol files.
Posted on 2006-02-18 07:20:48 by skywalker
Hi. Actually ,you dont need to do none of this. The symbolic info,that is provided by microsoft is for the system Applications and dll's and you dont need them to debug properly your project.
Working with windbg is not such easy thing to do, and if i should explain to you 'HOW TO' is better for me to start writing an article or tutorial. Unfortunately i dont have the time. So This is a small windbg project,that may show you alot of things.
You need to do the following steps. I had attached my personal settings of windbg, so you can use them too ,after entering them into the registry.
1st you need to click the settings.reg file in the attached archive, those are my settings.
2nd - click on DbgProjectExecute.reg
3th - WM_RBUTTONDOWN on the Project.wew file -> properties ->  open with -> windbg.
4th - double click on the project.wew file /ot from windbg menu file -> open workspace from file.

This is my favorit way to save my windbg projects - not into the registry as it's default mode, but in a workspace file.

The easy way for you to debug your own app is
1st to build it with debugging info (ml /Zi ; link /debug )
2nd open the executable in windbg -> menu ->open executable
3d open the ASM source file and setting you breakpoint.

That's it for now.
Bye.


http://www.freewebs.com/shaka_zulu/windbg_example_project.zip
Posted on 2006-02-28 13:14:39 by shaka_zulu

You must install the symbol files for the user-mode process that is being debugged.



.sympath SRV*c:\winsymbols*http://msdl.microsoft.com/download/symbols


I use this to auto-load symbols, followed by a '!reload' command, as needed when I resort to using WinDBG, but generally I use OllyDBG.
Regards,
Bryant Keller
Posted on 2006-02-28 13:46:51 by Synfire

Hi. Actually ,you dont need to do none of this. The symbolic info,that is provided by microsoft is for the system Applications and dll's and you dont need them to debug properly your project.
Working with windbg is not such easy thing to do, and if i should explain to you 'HOW TO' is better for me to start writing an article or tutorial. Unfortunately i dont have the time. So This is a small windbg project,that may show you alot of things.
You need to do the following steps. I had attached my personal settings of windbg, so you can use them too ,after entering them into the registry.
1st you need to click the settings.reg file in the attached archive, those are my settings.
2nd - click on DbgProjectExecute.reg
3th - WM_RBUTTONDOWN on the Project.wew file -> properties ->  open with -> windbg.
4th - double click on the project.wew file /ot from windbg menu file -> open workspace from file.

This is my favorit way to save my windbg projects - not into the registry as it's default mode, but in a workspace file.

The easy way for you to debug your own app is
1st to build it with debugging info (ml /Zi ; link /debug )
2nd open the executable in windbg -> menu ->open executable
3d open the ASM source file and setting you breakpoint.

That's it for now.
Bye.


http://www.freewebs.com/shaka_zulu/windbg_example_project.zip


I dled it twice and getting corrupt file.

Later.
Posted on 2006-02-28 14:00:00 by skywalker