Tracing Mov [esi], 00000002 of an external process

mmm, thanks. This has become much harder than anticipated! That code shows how to return the internal registers, but looking at another processes registers is a huge leap. So, unless i find how to invoke the target dlls registers (not happeneing), I think what I have to do is called 'one stepping' which should stop the address after an instruction, and allow you to examine registers. Atm, I'm looking into doing this with asm however it might be possible with other languages dunno. Thx Alan, I greatly appreciate the help!!

I thought I'd just see if I could make this idea work.

So I went into Visual Studio 2005 Tools -> Command Prompt, fired up Notepad, typed in the following program and saved it as esi.c:

#define DllExport __declspec(dllexport)

typedef unsigned int UINT;

DllExport UINT GetESIRegisterValue(void)
{

  UINT dwESI = 0;

  __asm
  {
    mov dwESI, esi
  }

  return dwESI;
 
}

 It was then compiled to a dll using this line:

cl  /LD esi.c

I then fired up Notepad again and typed in the following C# test program, showesi.cs:

using System;
using System.Runtime.InteropServices;

class Test
{
     [DllImport("esi.dll")]
     static extern uint GetESIRegisterValue();     

     static void Main()
     {
         uint esi = GetESIRegisterValue();
         Console.WriteLine(esi);
         Console.ReadKey();
     }
}

This was compiled to an .exe using the line:

csc showesi.cs

I then ran it and it appeared to work fine printing, FWIW, a value of  1242212 to the console :)

The addresses don't change often enough for speed to be an issue. That should work I suppose. No idea how to do that but hey, googles always fun

To the best of my knowledge, there are no .NET framework methods or anything in C# itself which would allow you to access CPU registers directly.

All I can suggest is that you write a C function containing inline assembly code to monitor the ESI register, export it from a dll and then P/Invoke it from C#. The question, of course, is whether this would be fast enough for 'real time' operations given the overhead of P/Invoke.