DEV Community: Josef Biehler

Read function arguments from .NET applications with .NET ProfilingAPI

Josef Biehler — Fri, 31 Jul 2020 14:53:45 +0000

Get the full runnable example: here

Today I want to guide you through the process of getting function parameters and return values. As always I am using the code from the last blogpost and extend it where necessary. For this article we have to adjust EnterCpp and the part of assembler code that calls this function.

While writing this lines I had no idea how this can be achieved. Of course I had the documentation about the FunctionEnter2 callback and it's parameter COR_PRF_FUNCTION_ARGUMENT_INFO *argumentInfo. But how I had to use it was not described. I also found no example in the world wide web but luckily I found someone who tried the same and was asking for help in the official dotnet repo. He doesn't get a complete working example but only a short explanation how he can get what he wants. This was enough for me to figure out the remaining stuff.

Modifying the Assembler code

Before we can start writing cool C++ code we must adjust the function signature of EnterCpp. When looking at the raw ICorProfiler definition of the enter callback, we can identify one additional argument that we should pass along with the FunctionId, named argumentInfo:

void FnEnterCallback(FunctionID funcId, UINT_PTR clientData, COR_PRF_FRAME_INFO func, COR_PRF_FUNCTION_ARGUMENT_INFO argumentInfo)

So let's change the signature of EnterCpp:

void EnterCpp(FunctionID funcId, COR_PRF_FUNCTION_ARGUMENT_INFO * argumentInfo)

In case of 64 bit assembler argumentInfo is the fourth parameter from left and thus is located in the register R9. To make it available to EnterCpp just copy it to RDX:

MOV RDX, R9

In case of 32 bit assembler, we have to push the correct value from the stack:

push [ESP+20]

Feel free to take a look into the code to see the full assembler code.

Necessary steps if we know the types

For this first try I assume that we know the types of the parameter and I know that the functions will have only one parameter. Using those preconditions makes it easier to get a first runnable example.

You need these steps:

Skip all functions whose name does not match our predefined set of functions
get a pointer to the function parameter
skip object header (if exists)
process data according to it's type

In the end this is not too hard to build. But as always, I needed a lot of try&error to get it right.

Skip functions

Well, this is easy. Just get the function name and compare it against our known function names. Utilize the Utils class for that:

char* fnName = new char[100];
utils->GetFunctionNameById(funcId, fnName, 100);

if (strcmp(fnName, "FunctionWithParameter") == 0) {
    //... do something
}

Get Pointer to function arguments

From what I have understand, the argumentInfo points to an struct that describes memory blocks with parameters. The reason for this is that parameters are not accessible in an continuous memory block but are split up for technical reasons.

argumentInfo->numRanges is the amount of such blocks
argumentInfo->ranges is an array of data

As we just have one parameter, this is not something we care about. So let's focus on argumentInfo->ranges[0].startAddress.

COR_PRF_FUNCTION_ARGUMENT_RANGE range = argumentInfo->ranges[0];
UINT_PTR valuePtr = range.startAddress;

So what is valuePtr? I haven't found a documentation about that but from what I have seen by debugging and testing, valuePtr is:

value type like 'int': a pointer to the value
object: a pointer to the Method Table pointer
Struct: a pointer to the struct

Skip object header

This article states that an object points to the Method Table Pointer and not to the beginning of the object data. Right now we don't need the information contained in the header and thus can skip it. Attention: Take care of the correct pointer size on 32 bit systems vs 64 bit systems. Of course you don't have to care about it if the parameter's type is not of type Object.

Process data

How can we interpret the data? Well, this depends on the data type. This raises the question, how we know the internal representation of the data? There are at least two possibilities to get an answer to this question. One is to read books and articles from Microsoft or other people about that topic. Another approach, which is sufficient in many times, is to use a .NET project + Visual Studio + Debugger to inspect the memory.

To do this we first need some C# code:

static void Main(string[] args)
{
    IntArrayFn(new int[] { 1,2,3,4,5,6,7,8,9,10});
}

static void IntArrayFn(int[] intArray)
{
    // place a breakpoint here and leave the method empty
}

Now execute the project as 64 bit application. This will produce function calls following the fastcall convention. That means that the parameters of IntArrayFn are passed from left to right in the registers RCX, RDX, R8, R9. This gives us the possibility to retrieve the memory address of the argument by inspecting the registers. Run the application and as soon as the breakpoint is hit, open Debugging > Window > Register to display the registers:

Copy the value from RCX (000002015C922F40) into Debugging > Window > Memory:

The first marked area is the pointer to the Method Table. The next 8 bytes represent the length of the array and after that you see the array elements with 4 bytes in size each.

Examples

Now I show you some examples. In every example I am using this code in EnterCpp:

extern "C" void _stdcall EnterCpp(
  FunctionID funcId,
  COR_PRF_FUNCTION_ARGUMENT_INFO * argumentInfo) {

  char* fnName = new char[100];
  utils->GetFunctionNameById(funcId, fnName, 100);

And this C# code in the test application:

using System;

namespace TestApp
{
  class Program
  {
    static void Main(string[] args)
    {
      Console.ReadLine();

      StructFn(new TestStruct { Int1 = 101, Int2 = 102, Int3 = 103 });
      IntArrayFn(new[] { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 });
      StringFn("Hello from C#");
      IntFn(1234);

      Console.ReadLine();
    }

    static void IntArrayFn(int[] intArray)
    {
    }
    static void StringFn(string str)
    {
    }

    static void IntFn(int i1)
    {
    }

    static void StructFn(TestStruct t)
    {
    }
  }

  struct TestStruct
  {
    public int Int1;
    public int Int2;
    public int Int3;
  }
}

IntFn

This is very easy. An integer is a value type and as such I can access it directly:

if (strcmp(fnName, "IntFn") == 0) {
    COR_PRF_FUNCTION_ARGUMENT_RANGE range = argumentInfo->ranges[0];
    UINT_PTR valuePtr = range.startAddress;
    int* ptr = (int*)valuePtr;

    std::cout << "\r\n\r\n## Entered IntFn ##\r\n";
    std::cout << "argument: " << *ptr << "\r\n";
    std::cout << "## IntFn ends ##";
}

StructFn

A struct also is a value type and thus can be handled like an integer. All fields of the struct are in memory one after the other:

if (strcmp(fnName, "StructFn") == 0) {
    COR_PRF_FUNCTION_ARGUMENT_RANGE range = argumentInfo->ranges[0];
    UINT_PTR valuePtr = range.startAddress;
    int* ptr = (int*)valuePtr;
    std::cout << "\r\n\r\n## Entered StructFn() ##\r\n";
    std::cout << "size of range: " << range.length << "\r\n";
    std::cout << "arguments: Int1 = " << *ptr << ", Int2 = " << *(ptr + 1) << ", Int3 = " << *(ptr + 2) << "\r\n";
    std::cout << "## StructFn() ends ##";
}

range.length is 12, because the struct consists of three fields where evry field needs four bytes.

IntArrayFn

Now we see the handling of the object header.

if (strcmp(fnName, "IntArrayFn") == 0) {
    COR_PRF_FUNCTION_ARGUMENT_RANGE range = argumentInfo->ranges[0];
    UINT_PTR valuePtr = range.startAddress;

    int** ptr = (int**)valuePtr;
    int* intArray = *ptr;

    std::cout << "\r\n\r\n## Enter IntArrayFn ##\r\n";
    intArray = intArray + sizeof(int*)/sizeof(int); //skip object header of array
    long arrayLength = *(long*)intArray;
    std::cout << "Length: " << arrayLength << "\r\n";
    intArray += sizeof(int*) / sizeof(int);
    std::cout << "Arguments: ";

    for (int i = 0; i < arrayLength; i++)
    {
      std:cout << "," << *intArray;
      intArray += 1;
    }

    std::cout << "\r\n## IntArrayFn ends ##";
}

sizeof(int*)/sizeof(int) is 2 in case of a 64 bit application and 1 for 32 bit applications.

Remember, raising a int* by one means to skip four bytes.

After skipping the header and reading the size, we have access to all array elements.

StringFn

A string is a little bit special because we have to convert it to print it to the console. I have copied a few lines of code for that task from a Stackoverflow article. Apart from this it is the same like in the integer array above:

if (strcmp(fnName, "StringFn") == 0) {
    COR_PRF_FUNCTION_ARGUMENT_RANGE range = argumentInfo->ranges[0];
    UINT_PTR valuePtr = range.startAddress;

    byte** ptr = (byte**)valuePtr;
    byte* strPtr = *ptr;
    strPtr = strPtr + sizeof(int*);
    long stringLength = *(long*)strPtr;
    strPtr += 4;
    char* dest = new char[100];

    std::wstring_convert<std::codecvt_utf8_utf16<char16_t>, char16_t> codecvt;
    std::string u8str = codecvt.to_bytes((char16_t*)strPtr);

    std::cout << "\r\n\r\n## Entered StringFn ##\r\n";
    std::cout << "Length: " << stringLength << "\r\n";
    std::cout << "\r\argument: " << u8str;
    std::cout << "\r\n## StringFn ends ##";

    delete[] dest;
}

Conclusion

As you can see, it is no big deal at all. I think I will try to get the values of unknown functions, too. This will be helpful in some debugging scenarios I think.

Additional Links

COR_PRF_FUNCTION_ARGUMENT_RANGE
Theoretical usage of COR_PRF_FUNCTION_ARGUMENT_RANGE
Memory Layout
Layout of managed Arrays

Found a typo?

As I am not a native English speaker, it is very likely that you will find an error. In this case, feel free to create a pull request here: https://github.com/gabbersepp/dev.to-posts . Also please open a PR for all other kind of errors.

Do not worry about merge conflicts. I will resolve them on my own.

'function enter/leave' + .NET profiler + 64Bit. Assembler code included!

Josef Biehler — Tue, 14 Jul 2020 18:34:48 +0000

Note: Get the full running example here

While beeing able to use inline assembler within a 32 bit project, you can not use that within a 64bit build. Microsoft just does not support this. You have to use an external .asm file instead which can be processed by MASM during the build process.

Assembler in VS

To activate MASM support in a C++ project in VS2019, please follow the guidelines in the official documentation. Additionally I suggest you to install the VS extension AsmDude to get syntax highlighting.

Switching between both implementations

To access the procedures that are defined in the assembler file, you must declare them with extern "C" in the header file. Otherwise the compiler rewrites the function names and thus the linker won't be able to match the CPP and ASM output together.

To see that effect, add a new function in a header file and call it somewhere in your CPP code. Then open the obj file and search the method name.

extern bool DevToTest(int a, int b);

Without the "C" addition, the name does not match the original one:

Using "C" fixes this:

extern "C" bool DevToTest(int a, int b);

To differentiate between 32 and 64 bit code, you can use preprocessor directives. Adjust Naked32Bit.h as following:

#pragma once
#include "pch.h"

#ifdef _WIN64

EXTERN_C void InitEnterLeaveCallbacks(bool* activate, int* hashMap, int size);

EXTERN_C void FnEnterCallback(FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo);

EXTERN_C void FnLeaveCallback(FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo);

EXTERN_C void FnTailcallCallback(FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func);

#else

void InitEnterLeaveCallbacks(bool* activate, int* hashMap, int size);
//....

#endif

In case of a 64 bit build, the functions refer to external symbols. I also adjusted the signature of the Init function. This was necessary because I wanted to show you how you can build the same logic as in the inline assembler. But this requires a hashmap. To avoid allocating memory in assembler, I just pass the variables from CPP into the assembler code. This saves me some time and makes the whole thing more readable.

Note: Of course the naming of the header file is not correct anymore, but this does not matter 😄

Now adjust Naked32bit.cpp:

extern "C" void _stdcall StackOverflowDetected(FunctionID funcId, int count) {
  std::cout << "stackoverflow: " << funcId << ", count: " << count;
}

extern "C" void _stdcall EnterCpp(
  FunctionID funcId,
  int identifier) {
  std::cout << "enter funcion id: " << funcId << ", Arguments in correct order: " << (identifier == 12345) << "\r\n";
}

#ifdef _WIN64

#else

bool* activateCallbacks;
int* pHashMap;
int mapSize;

void InitEnterLeaveCallbacks(bool* activate, int* hashMap, int size) {
  activateCallbacks = activate;
  pHashMap = hashMap;
  mapSize = size;
}

Both functions, EnterCpp and SODetected must be marked with extern "C". The Init function and the variables must be moved into the 32bit code block. You can leave the 64bit code block empty because everything will be in the assembler file.

Now add the initialize in ProfilerCOncreteImpl.cpp:

  this->PHashMap = new int[mapSize];
  memset(this->PHashMap, 0, mapSize);
  InitEnterLeaveCallbacks(&this->ActivateCallbacks, this->PHashMap, mapSize);

The ASM Code

What you will see now is no magic. There is only one thing you have to pay attention for: In 64Bt builds there is only one calling convention: fastcall. See the links at the end of the post to get an insight into it. The most important points (at least these are the points I came across a few times):

parameters are passed from left to right in the register: RCX, RDX, R8, R9
The caller must reserve 4*8 bytes in case of the callee wants to store the parameters onto the stack
The caller has to clean up the stack afterwards

I stumbled a few times over the last two points which led to unwanted behavior.

_DATA SEGMENT
  pActivateEnterLeaveCallback qword 0
  pHashMap qword 0
  mapSize dword 0
_DATA ENDS

extern EnterCpp:proc
extern StackOverflowDetected:proc

_TEXT   SEGMENT

PUBLIC InitEnterLeaveCallbacks

InitEnterLeaveCallbacks PROC
  mov pActivateEnterLeaveCallback, RCX
  mov pHashMap, RDX
  mov mapSize, R8D
  ret
InitEnterLeaveCallbacks ENDP

PUBLIC FnEnterCallback

FnEnterCallback PROC
  mov RAX, pActivateEnterLeaveCallback
  cmp byte ptr [RAX], 1
  JNE skipCallback

  mov R8, pHashMap
  MOV RAX, RCX
  XOR RDX, RDX
  DIV DWORD PTR [mapSize]
  ADD R8, RDX
  INC DWORD PTR [R8]
  CMP DWORD PTR [R8], 30
  JB skipStackOverflow

  xor rdx, rdx
  MOV EDX, [R8]
  SUB RSP, 20h
  CALL StackOverflowDetected
  ADD RSP, 20h

  skipStackOverflow:

  sub RSP, 20h
  mov rdx, 12345
  CALL EnterCpp
  add RSP, 20h

  skipCallback:
  ret
FnEnterCallback ENDP

PUBLIC FnLeaveCallback

FnLeaveCallback PROC
  MOV RAX, pActivateEnterLeaveCallback
  CMP BYTE PTR [RAX], 1
  JNE skipCallback

  MOV R8, pHashMap
  MOV RAX, RCX
  XOR RDX, RDX
  DIV DWORD PTR [mapSize]
  ADD R8, RDX
  DEC DWORD PTR [R8]

  skipCallback:
  ret
FnLeaveCallback ENDP

PUBLIC FnTailcallCallback

FnTailcallCallback PROC
  ret
FnTailcallCallback ENDP

_TEXT   ENDS

END

You see, nothing new here. sub RSP, 20h and add RSP, 20h are used to reserve memory on the stack and clean it up afterwards.

Using CPP implementations

As it seems that the CLR uses fastcall convention for calling the callbacks, you may assume that you can use CPP implementations instead of writing assembler code. Indeed I was able to do this:

#ifdef _WIN64
bool* activateCallbacks;
int* pHashMap;
int mapSize;


void InitEnterLeaveCallbacks(bool* activate, int* hashMap, int size) {
  activateCallbacks = activate;
  pHashMap = hashMap;
  mapSize = size;
}

void __fastcall FnEnterCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  if (activateCallbacks) {
    int amount = pHashMap[funcId % mapSize];
    amount++;
    pHashMap[funcId % mapSize] = amount;

    if (amount >= 30) {
      StackOverflowDetected(funcId, amount);
    }
    EnterCpp(funcId, 12345);
  }
}

void __fastcall FnLeaveCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  if (activateCallbacks) {
    pHashMap[funcId % mapSize] = pHashMap[funcId % mapSize] - 1;
  }
}

void __fastcall FnTailcallCallback(FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func) {
}
#else

During testing the code I don't see any errors but I don't know if this approach is intended by Microsoft.

Conclusion

The differences between 32 and 63 bit is not so big. I think the most relevant thing is the calling convention.

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

Trace 'function enter/leave' events with a .NET profiler + detect StackOverflow. Assembler code included!

Josef Biehler — Thu, 25 Jun 2020 18:46:58 +0000

Note: Get the full running example here: Click me!

The last time I showed some of the callbacks from ICorProfilerCallback and how you can obtain more information about the event. This time we want to take a look at the Function Enter/Leave callbacks.

Refactoring

As usual I took the project from the last post in this series. You may notice that I have changed the structure of the files. I moved all of the virtual dummy functions, that exists only because of the implementation of the ICorProfilerCallback2 interface, into an own class. This helps us to keep an overview about what we really want to focus on. Also I made a small fix in the project settings to ensure that both, x32 and x64 builds, are put into the same output directory. This was made to keep the start.bat as simple as possible.

COR_PRF_MONITOR_ENTERLEAVE

Today we are looking at the COR_PRF_MONITOR_ENTERLEAVE option which makes it possible to get notified if a function is entered and left. The callbacks are not declared on the ICorProfilerCallback interface but must be registered on the ICorProfilerInfo object. Use ICorProfilerInfo.SetEnterLeaveFunctionHooks2 for this task. Please note that the call to this method must occur during Initialize(), otherwise it is not valid. Also the callbacks are a bit special in the way you have to implement them 😄

Now Assembler comes into play

If we look into the documentation of FunctionEnter2, we can read a inconspicuous paragraph that tells us that:

"naked" advices the compiler to neither insert function prologue nor the epilogue at machine code level. The prologue consists of a few lines of code that prepares the CPU registers and the stack for the use within the function while the epilogue is the counterpart that restores the stack and registers before the function is left. This means, we should write our callbacks using inline assembler code. For those who immediately think that under x64 there is no inline assembler: Yes you are right. We will have a look at this in another blog post. In this I want to focus on 32 bit.

Well, how should this assembler code look like? You can, of course, try it on your own. I took a look into the official Microsoft example to get a clue how this should work. For the sake of a better overview I put all the inline assembler code into an own file (named naked32Bit.cpp).

Base Assembler Code

The base code is very simple:

void __declspec(naked) FnEnterCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  __asm {
    ret 16
  }
}

void __declspec(naked) FnLeaveCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  __asm {
    ret 16
  }
}

void __declspec(naked) FnTailcallCallback(FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func) {
  __asm {
    ret 12
  }
}

Note: The meaning of the parameter can be looked up in the documentation. The TailCallCallback is nothing I care about here because from what I have read this is not used (at least not very often).

What is the sense of ret 16? Well, both callbacks get four arguments passed into by pushing them onto the stack. As already mentioned, there is no epilogue that is capable of removing them from the stack again. So it's on us to clear the stack. Four parameters where each has a size of four bytes results in 16 bytes that must be removed from the stack.

Accessing the callback's arguments

When pushing function arguments onto the stack, the last parameter in the function definition gets pushed first. Calling the assembler command CALL results in another decrease of the stack pointer (SP) because the address of the opcode, that should be executed after the function, is pushed, too. This means that after arriving in the function, the SP must be raised by four bytes, to get the first parameter (was pushed directly before CALL occurred). To see this in action, we can create a small console application which writes the value in input into output:

#include<iostream>

__declspec(naked) void __stdcall Test(int input, int* output) {
    __asm {
        push EAX
        push EBX
        mov EAX, [ESP + 12] ;input
        mov EBX, [ESP + 16] ;output
        mov [EBX], EAX
        pop EBX
        pop EAX
        ret 12
    }
}

int main()
{
    int output = 0;
    Test(100, &output);
    std::cout << output;
}

Please note the __stdcall. This means that we clean up the stack on our own, exactly as we would do it in our callbacks. If you omitt this keyword, the compiler applies cdecl calling convention, which means that the caller cleans up the stack. ret 16 would lead to a corrupt stack in this case.

Why do we need [ESP + 12] to get the first argument? Well, SP points to the next execution address. In the function we see two push commands, which decrease the SP by another 2*4 = 8 bytes. So in the end we have to increase SP by 12 bytes to get the first argument.

By the way: You also would be able to use the names of the function parameters:

#include<iostream>

__declspec(naked) void __stdcall Test(int input, int* output) {
    __asm {
        push EBP
        mov EBP, ESP
        push EAX
        push EBX

        mov EAX, input ; <--- variable name
        mov EBX, output
        mov [EBX], EAX

        pop EBX
        pop EAX
        pop EBP
        ret 8
    }
}

int main()
{
    int output = 0;
    Test(100, &output);
    std::cout << output;
}

This is working because the compiler assumes where on the stack the arguments are:

_TEXT   SEGMENT
_input$ = 8                     ; size = 4
_output$ = 12                       ; size = 4
?Test@@YGXHPAH@Z PROC                   ; Test, COMDAT
; 4    :     __asm {
; 5    :         push EBP
  00000 55       push    ebp
; 6    :         mov EBP, ESP
  00001 8b ec        mov     ebp, esp
; 7    :         push EAX
  00003 50       push    eax
; 8    :         push EBX
  00004 53       push    ebx
; 9    : 
; 10   :         mov EAX, input
  00005 8b 45 08     mov     eax, DWORD PTR _input$[ebp]

In line 2 and 3 the position in the stack is defined. We see that "input" is accessible by [ESP:8]. I think the compiler assumes that we do a PUSH EBP and thus have to use the offset of 8 instead of 4, but I haven't investigated more about this.

A very simple approach to reduce the ASM code to as few lines as possible

If you want to reduce the necessary amount of assembler code to a minimum, you can call a C++ function from assembler. Please pay attention which calling convention you choose. To see if all arguments are passed in the right order, I added a second parameter:

void _stdcall EnterCpp(
  FunctionID funcId,
  int identifier) {
  std::cout << "enter funcion id: " << funcId << ", Arguments in correct order: " << (identifier == 12345) << "\r\n";
}

void __declspec(naked) FnEnterCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  __asm {
    ; push last parameter first!
    push 12345
    push [ESP+8]
    call EnterCpp
    ret 16
  }
}

Use more ASM code

I also want to show you an example that makes "heavy" use of Assembler code. Let's say you want to log function enter/leave only sometimes. As you must specify the callbacks during Initialize(), you can not completely deactivate the callbacks. So you might come up with the idea to use a flag that can be set from outside during the profiler session.

First we have to introduce a flag. This code should be in the same file where the Assembler code is:

bool* activateCallbacks;

void InitEnterLeaveCallbacks(bool* activate) {
  activateCallbacks = activate;
}

Then call this function in the Initialize():

bool activateCallbacks = false;

HRESULT __stdcall ProfilerConcreteImpl::Initialize(IUnknown* pICorProfilerInfoUnk)
{
  //...
  InitEnterLeaveCallbacks(&activateCallbacks);
  //...
}

Now add some simple ASM code that compares the flag's content with 1 ( = true) and if the check fails, it skips the processing of the function enter callback:

void __declspec(naked) FnEnterCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  __asm {
    push ebx
    mov ebx, [activateCallbacks]
    cmp byte ptr [ebx], 1
    JNE skipCallback

    ; push last parameter first!
    push 12345
    push [ESP+12]
    call EnterCpp

    skipCallback:
    pop ebx
    ret 16
  }
}

❗Please note❗: By using EBX to hold the flag's pointer, we have to increase ESP by another four bytes to get the FunctionID parameter.

Stackoverflow detection

What else could we do with it? Well, in .NET Framework a StackOverflowException is the worst case scenario. The application will crash immediately, mostly with no crash dumps available. The enter/leave notifications gives us a possibility to detect a SO, at least it can tell us where one might happen. First we create a integer array which serves as some kind of HashMap. It maps a FunctionID to the amount of calls to this function:

bool* activateCallbacks;
int* hashMap;
const int mapSize = 10000;

void InitEnterLeaveCallbacks(bool* activate) {
  activateCallbacks = activate;
  hashMap = new int[mapSize];
  memset(hashMap, 0, mapSize);
}

As the real SO handling will be much more complex (maybe), I call a C++ function if a SO is detected:

void _stdcall StackOverflowDetected(FunctionID funcId, int count) {
  std::cout << "stackoverflow: " << funcId << ", count: " << count;
}

Extend the already existing code by checking the amount of calls:

void __declspec(naked) FnEnterCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  __asm {
    push ebx
    mov ebx, [activateCallbacks]
    cmp byte ptr[ebx], 1
    JNE skipCallback

    ; check stackoverflow
    mov ebx, [hashMap]
    mov eax, [ESP + 8]
    xor edx, edx
    div dword ptr [mapSize]
    add ebx, edx
    inc dword ptr [ebx]
    cmp dword ptr [ebx], 30
    jb skipStackOverflow

    push [ebx]
    push [ESP + 12]
    CALL StackOverflowDetected

    skipStackOverflow:

    ; push last parameter first!
    push 12345
    push [ESP+12]
    call EnterCpp

    skipCallback:    

    pop ebx
    ret 16
  }
}

The code is not hard to understand, I think. By using a modulo operation we calculate the hash of the FunctionID and trace the depth of the call. But we also should decrease the amount of calls if the function returns:

void __declspec(naked) FnLeaveCallback(
  FunctionID funcId,
  UINT_PTR clientData,
  COR_PRF_FRAME_INFO func,
  COR_PRF_FUNCTION_ARGUMENT_INFO* argumentInfo) {
  __asm {
    push ebx
    mov ebx, [activateCallbacks]
    cmp byte ptr[ebx], 1
    JNE skipCallback

    mov ebx, [hashMap]
    mov eax, [ESP + 8]
    xor edx, edx
    div dword ptr [mapSize]
    add ebx, edx
    dec dword ptr [ebx]

    skipCallback:

    pop ebx
    ret 16
  }
}

Summary

I showed you how you can use the Enter/Leave callbacks on a x86 platform. In the next article we are going to extend this to 64 bit. This differs a bit because there is no inline assembler support for 64 bit platforms. So stay tuned!

Additional Links

Official example about how to write Enter/Leave callbacks
Another example for Enter/Leave
Additional ASM Code from MS for X64
Page 10: Which registers can be used

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

Prevent routing if unsaved changes exist [VueJS]

Josef Biehler — Wed, 10 Jun 2020 16:24:51 +0000

Let's say you have a input field and routes configured:

How can you avoid that the user navigates to a route if the inputfield contains unsaved text? I made a few tries to find a solution for that but did not found anything. So here is what I have done to solve this problem.

Find the full runnable example here: Click me!

Solution

First, define a new global function:

let isRouteChangeBlocked: boolean = false;

export function blockRouteChange(set?: boolean): boolean {
    if (arguments.length == 1) {
        isRouteChangeBlocked = !!set;
        return isRouteChangeBlocked;
    }

    return isRouteChangeBlocked;
}

Then use it to set the flag after the user make some input:

  @Watch("input")
  private inputChange(to: string) {
    if (to && to.length > 0) {
      blockRouteChange(true);
    } else {
      blockRouteChange(false);
    }
  }

After a successful saving, reset the flag:

  private save() {
    blockRouteChange(false);
    alert("saved");
  }

Now replace the router's push function:

const originalPush = VueRouter.prototype.push;
VueRouter.prototype.push = function(location: RawLocation) {
    if (blockRouteChange()) {
        if (confirm("There are unsaved changes, do you want to continue?")) {
            blockRouteChange(false);
            return originalPush.call(this, location) as any;
        }
        return;
    }
    return originalPush.call(this, location) as any;
};

Result

Here is what I got:

Conclusion

This workaround works really well but I'm wondering whether there isn't a better possibility? Do you know how this can be achieved using a native solution? Maybe I just was not clever enough to type in the correct search terms into google 😅 Just let me know.

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

Call function in unmanaged DLL from C# and pass custom data types [Marshal]

Josef Biehler — Sat, 06 Jun 2020 15:19:50 +0000

Note: Get the full runnable example here: Marshal example

During my last doings I needed to call a unmanaged library from .NET. That mechanism is called Platform Invoke (P/Invoke) can easily be done by using the DllImport attribute:

[DllImport("Dll1.dll")]
public static extern void Test();

But what if we want to pass some parameters? Let's say you have this C++ function definition:

void __stdcall Test(intptr_t pointer)

Well, this one is easy:

[DllImport("Dll1.dll")]
 public static extern void Test(IntPtr pointer);

No work must be done by you to get this running. The transition from IntPtr to intptr_t is done by .NET using Marshaling. This is somehow like sending data to a web server. In the client code you have a Date object but the server expects a DateTimeOffset. The transisition is done by using e.g. JSON representation and a JSON serializer that is capable of converting a string into the DateTimeOffset structure. There are many types that can be marshaled out of the box.

Sending custom datatypes

But what can we do, if we have a C++ signature like this:

struct TestFnParams {
    int A;
    char* B;
};

void __stdcall TestFunction(TestFnParams* p)

And a C# object like this:

public class TestFnParams
{
    public int PropertyA { get; set; }
    public string PropertyB { get; set; }
}

For this case .NET provides us with the capability to write an own Marshaler. In the following sections we are going to write a very simple one.

The C++ code

We just print both, the number and the string, that were passed in the struct. TestFunction expects a pointer to a TestFnParams struct:

// ./code/DLL1/dllmain.cpp#L20-L29

struct TestFnParams {
    int A;
    char* B;
};

void __stdcall TestFunction(TestFnParams* p) {
    std::cout << "Number: " << p->A << "\r\n";
    std::cout << "String: " << p->B << "\r\n";
    std::cout << "Hello from dll";
}

The C# code

First we define the class:

// ./code/ConsoleApp1/Program.cs#L70-L74

public class TestFnParams
{
  public int PropertyA { get; set; }
  public string PropertyB { get; set; }
}

And the main function:

// ./code/ConsoleApp1/Program.cs#L58-L67

static void Main(string[] args)
{
  var obj = new TestFnParams
  {
    PropertyA = 100,
    PropertyB = "Hello from managed object"
  };
  TestFunction(obj);
  Console.Read();
}

Now specify the DllImport attribute with a small difference to the normal usage:

// ./code/ConsoleApp1/Program.cs#L55-L56

[DllImport("Dll1.dll", CallingConvention = CallingConvention.StdCall)]
public static extern void TestFunction([MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof(CustomMarshaler))] TestFnParams p);

By using the MarshalAs attribute we can easily tell .NET to use our own marshaler.

Implementing the CustomMarshaler

Just create a new class and implement ICustomMarshaler. It has following methods:

object MarshalNativeToManaged (IntPtr pNativeData)

This method must be implemented if you are dealing with return values of custom types or out parameters. I don't use both so I skip it.

public IntPtr MarshalManagedToNative (object ManagedObj);

Used to convert the method parameter into the native representation.

public int GetNativeDataSize ();

From what I've understand, we can safely return -1 here because MarshalManagedToNative returns a pointer that always have a fixed size. In my test this method was not called at all.

public void CleanUpNativeData (IntPtr pNativeData);

Here we have to do the memory cleanup. Always remember, native data structures are unmanaged and thus you are responsible for the garbage collection.

public void CleanUpManagedData (object ManagedObj);

The cleanup hook for the managed objects. In our simple case we don't need it.

Also there is one constraint that must be fulfilled by the implementing class. It must provide a static method named GetInstance:

static ICustomMarshaler GetInstance(string pstrCookie);

The CLR is calling it in order to get an instance of the marshaler. This is necessary because the CLR will call that method once per application lifetime for every pstrCookie. So if you use the same function with different cookies, you can provide the CLR different instances. It is meant to be a singleton and thus should not hold any state.

Use different instances

The cookie can be specified within the MarshalAs attribute. Following code will call the same function but use another instance of the marshaler:

[DllImport("Dll1.dll", CallingConvention = CallingConvention.StdCall, EntryPoint = "TestFunction")]
public static extern void TestFunctionOtherCookie([MarshalAs(UnmanagedType.CustomMarshaler, MarshalTypeRef = typeof(CustomMarshaler), MarshalCookie = "OtherCookie")]TestFnParams p);

Until now, our implementation looks like this:

public class CustomMarshaler : ICustomMarshaler
{
    void ICustomMarshaler.CleanUpManagedData(object ManagedObj)
    {
    }

    void ICustomMarshaler.CleanUpNativeData(IntPtr pNativeData)
    {
        // to be defined
    }

    int ICustomMarshaler.GetNativeDataSize()
    {
        return -1;
    }

    IntPtr ICustomMarshaler.MarshalManagedToNative(object ManagedObj)
    {
        // to be defined
    }

    object ICustomMarshaler.MarshalNativeToManaged(IntPtr pNativeData)
    {
        throw new NotImplementedException();
    }

    public static ICustomMarshaler GetInstance(string cookie)
    {
        return new CustomMarshaler();
    }
}

Implement MarshalManagedToNative

First you have to know what kind of data the native function expects. In this case it is a pointer to a struct. How does the struct look like?

struct TestFnParams {
    int A;
    char* B;
};

In the memory you just have 8 bytes (in a 32bit process) somewherre in the memory where the first four bytes represent the integer A and the subsequent four bytes represent the pointer to the string B. To provide native data you have to allocate memory and write into it. Fortunatelly there is the Marshal class that provides a few functions to us:

AllocHGlobal(size): requests a memory block with the specified size in bytes
Write*: functions to write into that memory block

So let's start by casting the function parameter:

// ./code/ConsoleApp1/Program.cs#L24-L30

IntPtr ICustomMarshaler.MarshalManagedToNative(object ManagedObj)
{
  var casted = ManagedObj as TestFnParams;
  if (casted == null)
  {
    return IntPtr.Zero;
  }

Now we must use AllocHGlobal. But how many bytes do we need? Of course we need the mentioned 8 bytes to represent the struct. To support both, 32bit and 64 bit, use sizeof:

var ptr = Marshal.AllocHGlobal(sizeof(int) + Marshal.SizeOf(typeof(IntPtr)));

The next step is to write the integer PropertyA into that memory block:

Marshal.WriteInt32(ptr, casted.PropertyA);

To write the string PropertyB into the native memory, following steps are required:

allocate a memory block with the size: PropertyB.Length + 1. Mind the +1 which is for holding the terminating \0 byte.
write that pointer to [ptr + 4]
write the char bytes to the newly allocated memory

And this is the code:

// ./code/ConsoleApp1/Program.cs#L34-L39

var bytes = Encoding.UTF8.GetBytes(casted.PropertyB);
var strPtr = Marshal.AllocHGlobal(bytes.Length + 1);
Marshal.Copy(bytes, 0, strPtr, bytes.Length);
Marshal.WriteByte(strPtr + bytes.Length, 0);
Marshal.WriteIntPtr(ptr + sizeof(int), strPtr);
return ptr;

That's all. You just marshaled a managed object successfully to a native function. The last step is to return the pointer to your manually created struct: return ptr;. This will be the function parameter which is received by the native function.

Conclusion

I didn't expect this being so easy to implement (of course I don't have choosen the most complexe example here). The whole code (including reading documentation and troubleshooting) was written in under two hours if I remember correctly. One mistake that costs very much time was that I tried to copy the char bytes to [ptr + 4] what was completeley wrong of course:

var ptr = Marshal.AllocHGlobal(sizeof(int) + casted.PropertyB.Length);
Marshal.WriteInt32(ptr, casted.PropertyA);
var bytes = Encoding.UTF8.GetBytes(casted.PropertyB);
Marshal.Copy(bytes, 0, ptr + 4, bytes.Length);

Additional links

ICustomMarshaler
Long Marshaler
Understanding Custom Marshaling
More examples using marhsal cookie
Types

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

[Win32 / Hooks / Spy++] How I got rid of those useless mouse buttons using Windows Hooks

Josef Biehler — Wed, 03 Jun 2020 06:22:37 +0000

Note: Get the code here: Full runnable example

A few months ago my computer mouse stopped working so I bought one of those cheap ones. It is working like a charm but unfortunately it has two very very annoying side buttons:

I don't remember ever using them. Most of the time they and me coexist peacefully but sometimes (often when my wife is in front of the computer) the get clicked accidentally. It is not a drama after all, you think? Well it is if you are sitting in front of your email provider's sending mask, typing a large text into it and accidentally click this strange side button that is mapped to the back button...

So I always wanted to get rid of them, but:

Windows is not able to control those buttons
the manufacturer does not provide a software for it
removing the buttons from the mouse is not really a satisfactory solution for that problem

The very last solution

Today I scanned my bookshelf and suddenly an old book, bought and read about 12 years ago, catches my eye:

After reading the table of contents:

I saw the part with Hooks. And suddenly something I've done several years ago came back into my mind. Windows is based upon a message system and there is a powerful function that let's you inspect every message. And in one case you are also able to modify the messages. So maybe you got my idea: Listen to a specific message and omit it so that the mouse click message never reaches any application.

Windows Message

If you press a key, someone sends somewhere a WM_CHAR message. If you press the left mouse button, a WM_LBUTTONDOWN is sent. Those events are fetched by applications that respond to them or skip them.
E.g. having a WPF application with just a single button introduces a consumer of WM_LBUTTOMDOWN events and of course it also consumes the corresponding WM_LBUTTONUP events.

See windows messages in action

If you have Visual Studio installed, you have access to a little tool from Microsoft, called Spy++. You find it in the installation directory, e.g.:



C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\Tools

The folder contains two versions, a 32 Bit and a 64 Bit version. You must choose it based on the bitness of the application you want to inspect. The WPF application is executed as 32Bit application so I open that version. Click onto the button I've marked red in this screenshot. A new window appears:

Now click onto the crossfade, hold the button, move it over the application you are interested in and click the "OK" button. You are now tracing that application:

You see, there is a bunch of messages that were emitted all the time.

Determine the right message

So you know that there is a message if something happens on the keyboard or the mouse. How do you know what message we are interested in? Just trigger it and "listen" to the message stream. In this case I recommend to remember the last row number:

Then place the mouse over the test app and press one of the side button. In my case the last message right before the click was: 1730 Right click onto the message stream and stop recording:

You now have a bunch of new messages. I wish you luck in finding the right one 😄 In my case I assumed that WM_XBUTTONDOWN is what I am looking for:

Of course, just an assumption.

Hooking

We have to differentiate between a local hook and a global hook. As stated in the official documentation a global hook can monitor all events in all threads and must be placed into a own DLL.

To register a hook, we use SetWindowsHookEx. It requires the type of the hook as first parameter. To get a full list of possible values, refer to the official documentation.

Blocking a message

We are interested in WH_GETMESSAGE. Whenever a windows application calls GetMessage() to retrieve the next message for dispatching (every application is doing this all the time 😄), WH_GETMESSAGE is emitted. This is the only place where you can modify the message. After returning from the hook callback, the message is passed to the application that calls GetMessage(). So whatever you write into the message will be visible to to the caller. This means, here we can adjust the message to prevent WM_XBUTTONDOWN being processed. To do so, replace the original message with WM_NULL.

Writing the start application

My intention is, to have a small application, staying in the systray, that provides three functions:

Enable Buttons
Disable Buttons
Close App

Calling unmanaged code from C

As already mentioned, we need a DLL to make this happen. I am writing the DLL in C++ and thus we need to call unmanaged code from our managed application. Fortunately C#/.NET makes it easy for us to do so! Let's say there exist two methods: SetHook and RemoveHook (with std calling convention) and the DLL will be named DLL1.dll, then you simple have to put those two DllImport statements at the root of the application's class:



[DllImport("Dll1.dll", CallingConvention = CallingConvention.StdCall)]
public static extern void SetHook();

[DllImport("Dll1.dll", CallingConvention = CallingConvention.StdCall)] 
public static extern void RemoveHook();

Very easy!

Systray Icon

There is nothing special about the code. I used a WinForms application type because there it is much easier to setup a systray icon than with a WPF application.



// ./code/App/Program.cs

using System;
using System.Drawing;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace App
{
    static class Program
    {
        private static NotifyIcon notifyIcon;

        [DllImport("Dll1.dll", CallingConvention = CallingConvention.StdCall)]
        public static extern void SetHook();

        [DllImport("Dll1.dll", CallingConvention = CallingConvention.StdCall)] 
        public static extern void RemoveHook();

        private static void SetText(bool? disabled = null)
        {
            notifyIcon.Text = "Disable XButton App";

            if (disabled == true)
            {
                notifyIcon.Text += " [Disabled]";
            } 
            else if (disabled == false)
            {
                notifyIcon.Text += " [Enabled]";
            }
        }

        private static void InitIcon()
        {
            notifyIcon = new NotifyIcon();
            notifyIcon.Icon = new Icon("example.ico");
            SetText();
            notifyIcon.Visible = true;
            notifyIcon.ContextMenuStrip = GetContextMenu();
        }

        private static ContextMenuStrip GetContextMenu()
        {
            var cm = new ContextMenuStrip();
            var item = new ToolStripMenuItem();
            item.Text = "Disable buttons";
            item.Click += DisableClick;
            cm.Items.Add(item);

            item = new ToolStripMenuItem();
            item.Text = "Enable buttons";
            item.Click += EnableClick;
            cm.Items.Add(item);
            cm.Items.Add(new ToolStripSeparator());

            item = new ToolStripMenuItem();
            item.Text = "Close";
            item.Click += CloseClick;
            cm.Items.Add(item);

            return cm;
        }

        private static void CloseClick(object sender, EventArgs e)
        {
            Application.Exit();
        }

        private static void EnableClick(object sender, EventArgs e)
        {
            SetText(false);
            RemoveHook();
        }

        private static void DisableClick(object sender, EventArgs e)
        {
            SetText(true);
            SetHook();
        }

        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            InitIcon();
            Application.Run();
            notifyIcon.Dispose();
        }
    }
}

Result:

Writing the DLL

I just created a new DLL project in Visual Studio and deleted everything I don't need. This is what was left:



// ./code/Dll1/dllmain.cpp#L1-L16

#include "pch.h"

HHOOK hkKey = NULL;
HINSTANCE hInstHookDll = NULL;
LRESULT CALLBACK GetMsgProc(int code, WPARAM wParam, LPARAM lParam);

BOOL APIENTRY DllMain(HANDLE hModule, DWORD  reasonForCall, LPVOID lpReserved)
{
    switch (reasonForCall)
    {
    case DLL_PROCESS_ATTACH:
        hInstHookDll = (HINSTANCE)hModule;
        break;
    }
    return TRUE;
}

Then we need a function that can set the hook:



// ./code/DLL1/dllmain.cpp#L18-L21

void __stdcall SetHook()
{
    if (hkKey == NULL)
        hkKey = SetWindowsHookEx(WH_GETMESSAGE, GetMsgProc, hInstHookDll, 0);

And one that can remove the hook:



// ./code/DLL1/dllmain.cpp#L24-L29

void __stdcall RemoveHook()
{
    if (hkKey != NULL)
        UnhookWindowsHookEx(hkKey);
    hkKey = NULL;
}

The main part surely is the hook callback:



// ./code/DLL1/dllmain.cpp#L31-L41

LRESULT CALLBACK GetMsgProc(int code, WPARAM wParam, LPARAM lParam)
{
    if (code >= 0 && code == HC_ACTION)
    {
        MSG* msg = (MSG*)lParam;
        if (msg->message == WM_XBUTTONDOWN || msg->message == WM_XBUTTONUP) {
            msg->message = WM_NULL;
        }
    }
    return CallNextHookEx(hkKey, code, wParam, lParam);
}

What happens in this few line of code:

int code: according to the Microsoft documentation we can forward this call to the next hook if code <> HC_ACTION
lParam contains a pointer to a MSG struct
if the message is equal to WM_XBUTTONDOWN or WM_BUTTONUP replace the message with WM_NULL

32 Bit vs. 64 Bit

The hook DLL is injected into every process. The hook code is executed within the context of the hooked application. This means that using a 32 Bit DLL will block the XButtons in 32Bit applications but not in 64Bit applications. If you want to block the buttons in all applications, you must create a 32Bit and a 64Bit DLL.

Troubleshooting

If you are not able to call SetHookand RemoveHook you should check if you exported the functions correctly. To do this, open the Developer Command Prompt for VS, change the working directory to the folder where your DLL was filed and execute:



dumpbin /exports dll1.dll

The result should look similar to this:

Summary

I showed you how you can block mouse buttons using only a few lines of code. This approach can be extended to many other use cases, too.

Additional Links

System-Wide-Hooking-for-the-WM-CHAR-Message
Hook on Mouse with Win32 api

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

Controlling the file chooser within a Cypress.io test

Josef Biehler — Mon, 25 May 2020 21:04:55 +0000

Note: Get the code here

OK. So you decided to do a real file upload test in Cypress? I appreciate your decision! First you should read through this post:

Doing native clicks with Cypress.io and open file dialog

Josef Biehler ・ May 23 '20

#cypress #javascript #debug #testing

Now I have to warn you: This solution will only work on Windows!

My solution - quick and dirty

I make use of the fact that Chrome uses the system file dialog and not something own. Due to that we can rely on the Windows Messaging system and can control the dialog by Win32 API calls. I won't go too much into the details because there are a bunch of good tutorials out there that describe the Win32 API and the Windows Messages better than me ever could. 😄

Using Win32 API Calls in CSharp

To use functions like SendMessage and FindWindowEx you have to load user32.dll. To make your C# life easier, I recommend the usage of PInvoke.net, a collection of many calls into the system DLLs and often with some example code!

In my case I was able to copy & paste the example for SendMessage and FindWindowEx without adjustments.

File Dialog Handles

Let's examine the Window structure of the dialog. I use Microsoft Spy++ for this task. You can find it in your Visual Studio installation path:



C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\Tools\spyxx_amd64.exe

First we look for a Window whose title is Öffnen / Open:

Now as we have the parent handle, we can successively go downwards and select the ComboBoxEx32 > ComboBox > Edit:

The code is very simple:



// ./code/tool/Tool/Tool/Program.cs#L21-L26

IntPtr fileChooserHandle = FindHandle(IntPtr.Zero, null, "Öffnen");

var comboboxExHandle = FindHandle(fileChooserHandle, "ComboBoxEx32", null);
var comboboxHandle = FindHandle(comboboxExHandle, "ComboBox", null);
var editHandle = FindHandle(comboboxHandle, "Edit", null);
var btnHandle = FindWindowEx(fileChooserHandle, IntPtr.Zero, "Button", null);

I use a fail-safe implementation that tries several times to get the handle. Actually I only need this for the fileChooserHandle because it may take some time to open the dialog. If we request the handle to early, the whole process will fail.



// ./code/tool/Tool/Tool/Program.cs#L37-L56

static IntPtr FindHandle(IntPtr parentHandle, string className, string title)
{
  IntPtr handle = IntPtr.Zero;

  for (var i = 0; i < 50; i++)
  {
    handle = FindWindowEx(parentHandle, IntPtr.Zero, className, title);

    if (handle == IntPtr.Zero)
    {
      Thread.Sleep(100);
    }
    else
    {
      break;
    }
  }

  return handle;
}

Setting the file path

We just have to send WM_SETTEXT message to the Edit component and click the "Öffnen / Open" button:



// ./code/tool/Tool/Tool/Program.cs#L28-L34

// WM_SETTEXT
SendMessage(editHandle, 0x000C, IntPtr.Zero, new StringBuilder(args[0]));

// LeftButtonDown
SendMessage(btnHandle, 513, IntPtr.Zero, null);
// LeftButtonUp
SendMessage(btnHandle, 514, IntPtr.Zero, null);

Calling it from Cypress.io

You have to add a new task:



// ./code/cypress/cypress/plugins/index.js#L37-L43

selectFile: async(value) => {
  return new Promise(resolve => {
    execFile("C:/git/dev.to-posts/blog-posts/cypress-file-chooser/code/tool/Tool/Tool/bin/Debug/Tool.exe", [value], {}, (error) => {
      resolve("ready" + JSON.stringify(error));
    })
  })
},

Don't forget the execFile import:



const {execFile} = require("child_process")

And use it as always:



// ./code/cypress/cypress/integration/spec.js#L15-L26

cy.get("input").first().then($element => {

  const element = $element[0];

  element.scrollIntoView();

  var rect = element.getBoundingClientRect();

  // wait only needed for demonstration purposes

  cy.task("nativeClick", {x: parseInt(rect.x) + addX, y: parseInt(rect.y) + addY })

  .wait(1000)

  .task("selectFile", "C:\git\dev.to-posts\blog-posts\cypress-file-chooser\code\cypress\package.json")

  .wait(1000)

  .get("div", { timeout: 10000 })

  .should("contain", "package.json")

})

Caveats

If you have two file dialogs open, the outcome of that search is not deterministic! If this is the case in your setup you have to adjust the code that looks for the dialog handle. I just made it very simple. You can of course adjust the search logic just as you need it.
Use backslashes in the path! Otherwise the file dialog won't accept the path!

Additional Links

Microsoft Spy++
Windows Messages
WM_LBUTTONDOWN
WM_LBUTTONUP
PInvoke.net: Win32 API Calls in .NET

Summary

I showed you how you can control the File Dialog. Using this approach you can build very realistic file upload test scenarios. This approach can be extended to other use cases as well. Let me know if you have another use case for that!

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

Doing native clicks with Cypress.io and open file dialog

Josef Biehler — Sat, 23 May 2020 13:33:25 +0000

Note: Get the code here

There are some rare cases where cy.get(...).click() won't work properly. If you encounter such a situation, you should give this approach a try. In this post we are opening the file chooser programmatically by click.

Application under test

We use a very simple HTML construct:

<!-- ./code/index.html -->

<html>
<head>
    <style>
        html, body {
            margin: 0;
            padding: 0;
        }
    </style>
</head>
<body>
    <input type="file">Choose your file!</input>
</body>
</html>

So nothing special. Let's now write a test that clicks into that button.

Open file dialog

We do a simple cy.get("input").click();. You should now see nothing. Open the DevTools and you should see a warning:

Opening the file chooser by code has been disabled due to security reasons, which makes sense of course.

Native events vs. synthetic events

Synthetic events are called that ones you call normally in your code, like $el.click(). They are simulated and produced by Javascript. Native events are produced by the browser. The latter simulate the user behavior better but lack the possibility that synthetic events provide.

Using a native click event you can instruct the browser to click onto the screen at position x:y whereas using a synthetic click you can instruct to trigger a click event on element div[id='test']. So what is the difference? Imagine a button that is covered completely by a div whose z-index is higher. Doing a native click onto the button won't have an effect because the div receives it. Doing a synthetic click onto the button will trigger the button's click event handler.

Trigger native events

Native events can be emitted by at least two different approaches:

using Windows Messages (low level Win32 API call to SendMessage)
using Chrome Debugger Protocol

As I don't think that Windows Messages is necessary, I will focus on the latter 😄

Chrome Debugger Protocol

I've already written a blog post about using it in Cypress, so I won't repeat everything.

Low level access to Chrome Debugger Protocol and Cypress

Josef Biehler ・ Jan 5 '20

#cypress #testing #debug #chrome

Mouse event

The method for emitting a mouse event is called Input.dispatchMouseEvent and needs at least following parameters to work for our use case.

Pressing the mouse

{
    "id": 1,
    "method": "Input.dispatchMouseEvent",
    "params": {
        "type": "mousePressed",
        "button": "left",
        "x": ...,
        "y": ...,
        "clickCount": 1
    }
}

Releasing it

{
    "id": 2,
    "method": "Input.dispatchMouseEvent",
    "params": {
        "type": "mouseReleased",
        "button": "left",
        "x": 519,
        "y": 46,
        "buttons": 1,
        "clickCount": 1
    }
}

When releasing it you must set buttons to 1 which tells chrome that when sending the Release event, the left mouse button is pressed. Leaving this optional parameter empty did not work for me.

The x and y coordinates are relative to the top left edge in the viewport:

Getting X and Y

You might come up with the idea to do this to get the X/Y coordinates:

cy.get("input").then($elements => {
  var first = $elements[0];
  var rect = first.getBoundingClientRect();
  var x = rect.x;
  var y = rect.y;
})

Unfortunately this is not correct:

In the picture it shows 0 for both, x and y. But (0|0) would produce a click to the top left edge of the viewport which is not what we want. The problem is that Cypress renders the application within an iframe:

But a native click event does not know what an iframe is. And the application does not know that there is a world outside of it.

To solve this issue you can select the div with the class size-container (it contains the iframe), retrieve its x and y and adding them onto the element's x and y. But keep in mind that there are iframes involved so you must choose the right one:

// ./code/cypress/integration/spec.js#L10-L25

it('file dialog open succeeds', () => {
  const sizeContainer = window.frames["parent"].document.querySelector(".size-container");
  const cypressAppFrameContainerRect = sizeContainer.getBoundingClientRect();
  const marginLeft = parseFloat(getComputedStyle(sizeContainer).marginLeft);

  // pixel values passed to chrome debugger protocol must be integer
  const addX = Math.ceil(cypressAppFrameContainerRect.x + marginLeft);
  const addY = Math.ceil(cypressAppFrameContainerRect.y);

  cy.get("input").first().then($element => {
    const element = $element[0];
    element.scrollIntoView();
    var rect = element.getBoundingClientRect();
    cy.task("nativeClick", {x: parseInt(rect.x) + addX, y: parseInt(rect.y) + addY });
  })
})

element.scrollIntoView(); is necessary because we can't do a native click onto an element that is not within the visible area!

You also have to add the left-margin:

Sending the event

Based upon the logic from the mentioned blog post we add a new Cypress task:

// ./code/cypress/plugins/index.js#L30-L35

nativeClick: async({ x, y }) => {
  client = client || await CDP({ port })
  await client.Input.dispatchMouseEvent( { type: "mousePressed", x, y, button: 'left', clickCount: 1 });
  await client.Input.dispatchMouseEvent( { type: "mouseReleased", x, y, button: 'left', clickCount: 1, buttons: 1 });
  return Promise.resolve(true);
},

Result

Of course this code will open the file dialog 😄

Troubleshooting

When using this approach you should close the DevTools because otherwise the click event may be received by the DevTool Window. I haven't investigated this yet but maybe the command chooses the first available window to be fired on. If you need the DevTools to be opened during that command you should consider to take a look into the Chrome DevTools protocol to find a way to choose the right window.

Summary

I have shown you how to do native events with Cypress. Do you ever had to use native events? let me know. I'm interested in the real world use cases.

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

Digging into a few callbacks and how you can obtain more information about an event

Josef Biehler — Fri, 15 May 2020 08:29:25 +0000

A few callbacks explained

Until now we setup a simple profiler that is capable of logging every exception. Do you remember the output? It was just exception thrown, which may be useful but surely it will be much more useful if the exception name would be printed.

If you looked at several callback methods, you may have noticed, that often you get only an id. E.g. a FunctionId or a ClassId and such things. This makes sense as passing more information to the callbacks will increase the overall CPU & RAM load. On the other hand, you have to call a few methods to get more information. Unfortunately it is often not very obviously what kind of method you have to use. At least I found it a bit confusing. But maybe the whole process is documented somewhere in the .NET documentation 😄

To make your life easier, I will show you some use cases. I will not write too much about it. I mean, I'm only calling some functions in a very stupid manner. So if you have questions, please ask and I'll try to answer them.

ExceptionThrown callback

Let's take the example project from the last lesson. There we implemented the ExceptionThrown callback. As parameter you only get an ObjectID. Wouldn't it be nice if we could print the name of the exception? Let's do this.

Utils

I create an own class for the methods that retrieve more information about an event. Let's call it Utils. You should be aware that I will not write the most performant code and you may encounter a lot of things that could be improved. But be sure that all of this has been done for easier understanding.

Get class name by object ID

To get more information about an event, utilize the instance of type ICorProfilerInfo.

bool Utils::GetClassNameByObjectId(ObjectID objectId, char* output, ULONG outputLength) {
  ClassID classId;
  iCorProfilerInfo->GetClassFromObject(objectId, &classId);
  return this->GetClassNameByClassId(classId, output, outputLength);
}

bool Utils::GetClassNameByClassId(ClassID classId, char* output, ULONG outputLength) {
  ModuleID moduleId;
  mdTypeDef typeDefToken;
  IMetaDataImport* metadata;
  wchar_t* className = new wchar_t[outputLength];
  ULONG read = 0;

  HRESULT hresult = iCorProfilerInfo->GetClassIDInfo(classId, &moduleId, &typeDefToken);

  if (hresult < 0 || moduleId == 0) {
    return false;
  }

  hresult = iCorProfilerInfo->GetModuleMetaData(moduleId, ofRead, IID_IMetaDataImport, (IUnknown**)&metadata);
  hresult = metadata->GetTypeDefProps(typeDefToken, className, outputLength, &read, NULL, NULL);
  metadata->Release();

  memset(output, 0, outputLength);
  wcstombs(output, className, outputLength);
  delete[] className;
  return true;
}

The callback needs to call the utility class:

HRESULT __stdcall ProfilerCallback::ExceptionThrown(ObjectID thrownObjectID)
{
  char* className = new char[100];
  utils->GetClassNameByObjectId(thrownObjectID, className, 100);
  cout << "\t\nfrom profiler: exception thrown: " << className << "\r\n";
  delete[] className;
  return S_OK;
}

And this is the output:

ObjectAllocated callback

We can use the newly created utility method to print every allocated object. Set following flags: COR_PRF_MONITOR_OBJECT_ALLOCATED | COR_PRF_ENABLE_OBJECT_ALLOCATED.

And implement the callback:

HRESULT __stdcall ProfilerCallback::ObjectAllocated(ObjectID objectID, ClassID classID)
{
  char* className = new char[1000];
  if (utils->GetClassNameByClassId(classID, className, 1000)) {
    cout << "\t\nfrom profiler: class allocated: " << className << "\r\n";
  }
  delete[] className;
  return S_OK;
}

Retrieving stacktraces

Let's say you want to observe all allocations of type CatBowlEmptyException and print out the stacktrace so you know where this happened. Fortunately the Profiler API provides you the ICorProfilerInfo2::DoStackSnapshot method which requests a stacktrace of the current thread (or of another one, but I won't cover this here). It awaits a pointer to a function that is called for every frame in the stacktrace. The requesting and the providing of the frames are synchronous which means, the next line after DoStackSnapshot is executed after the last frame was reported.

Activate

You must use the flag COR_PRF_ENABLE_STACK_SNAPSHOT to be able to request snapshots:

 iCorProfilerInfo->SetEventMask(.... | COR_PRF_ENABLE_STACK_SNAPSHOT);

Signature of DoStackSnapshot

DoStackSnapshot( 
ThreadID thread,
StackSnapshotCallback *callback,
ULONG32 infoFlags,
void *clientData,
BYTE context[  ],
ULONG32 contextSize)

thread: You can pass 0 which means you want to retrieve the stacktrace of the current thread.
callback: See the discussion below
infoFlags: Indicates whether a context containing the CPU state should be passed to the callback. In our simple example we don't care, so use COR_PRF_SNAPSHOT_DEFAULT here
clientData: This is a pointer to anything you want to pass to the callback. You can use 0 if you don't want to pass anything.
context: 0 if you want to retrieve the stacktrace of the current thread
contextSize: also 0

Signature of the Callback

DoStackSnapshotCallback(
    FunctionID funcId,
    UINT_PTR ip,
    COR_PRF_FRAME_INFO frameInfo,
    ULONG32 contextSize,
    BYTE context[],
    void* clientData
)

funcId: The FunctionId which can be used to get the function name. It is 0 if the current frame is an unmanaged function call. For this blog post I skip that frame in those cases.
ip: Instruction pointer
frameInfo: To be honest, I have no idea what data resists in that struct and I have not found any definition of that struct.
contextSize, context: both will be null because we don't request them for this blog post
clientData: exactly that thing you could pass in DoStackSnapshot.

Getting the function name based on the `FunctionID`

Add a new function to Utils.cpp:

bool Utils::GetFunctionNameById(FunctionID functionId, char* output, ULONG outputLength) {
  IMetaDataImport* metadata;
  mdMethodDef methodToken;
  mdTypeDef typeDefToken;
  wchar_t* functionName = new wchar_t[1000];
  ULONG wcbCount;
  memset(functionName, 0, 1000);
  iCorProfilerInfo->GetTokenAndMetaDataFromFunction(functionId, IID_IMetaDataImport, (IUnknown**)&metadata, &methodToken);
  metadata->GetMethodProps(methodToken, &typeDefToken, functionName, 1000, &wcbCount, NULL, NULL, NULL, NULL, NULL);
  wcstombs(output, functionName, outputLength);
  metadata->Release();
  delete[] functionName;
  return true;
}

I assumed that the last parameters of GetMethodProps are all optional. At least this compiles and runs without errors :-)

Gimme the code - ObjectAllocated

We slightly adjust the ObjectAllocated callback:

HRESULT __stdcall ProfilerCallback::ObjectAllocated(ObjectID objectID, ClassID classID)
{
  char* className = new char[1000];

  if (utils->GetClassNameByClassId(classID, className, 1000)) {
    cout << "\t\nfrom profiler: class allocated: " << className << "\r\n";

    if (strcmp(className, "TestApp.CatBowlEmptyException") == 0) {
      char* stack = new char[1000];
      memset(stack, 0, 1000);
      SnapshotClientData clientData;
      clientData.pUtils = utils;
      clientData.stacktrace = stack;

      iCorProfilerInfo->DoStackSnapshot(NULL, &DoStackSnapshotCallback, COR_PRF_SNAPSHOT_DEFAULT, &clientData, 0, 0);
      cout << "stack:\r\n" << stack;

      delete[] stack;
    }   
  }

  delete[] className;
  return S_OK;
}

SnapshotClientData is a struct created by me to transport the Utils object and a pointer to the stack char array:

struct SnapshotClientData {
  Utils* pUtils;
  char* stacktrace;
};

Gimme the code - DoStackSnapshotCallback

HRESULT __stdcall DoStackSnapshotCallback(
  FunctionID funcId,
  UINT_PTR ip,
  COR_PRF_FRAME_INFO frameInfo,
  ULONG32 contextSize,
  BYTE context[],
  void* clientData
) {
  if (funcId == 0) {
    return S_OK;
  }

  SnapshotClientData* snapshotClientData = (SnapshotClientData*)clientData;
  char* output = snapshotClientData->stacktrace + strlen(snapshotClientData->stacktrace);
  output[0] = '\r';
  output[1] = '\n';
  output += 2;
  snapshotClientData->pUtils->GetFunctionNameById(funcId, output, 1000);

  return S_OK;
}

I manipulated the pointer output to append the next frame to output plus a new line. Not sure if this is considered to be best practice in C++ 😅

Please note that I added the callback not to the ProfilerCallback class because I did not succeed in passing a pointer to a member function into DoStackSnapshot.

Outcome

Given a weird and senseless program with some nested calls I get this output:

Summary

I showed you some use cases and how you can handle them. I hope you got a little insight into the process of event handling. In one of the next article we are taking a look at FunctionEnter and FunctionLeave stuff. But be aware to see some ASM code 😄 Also I try to retrieve the line number from a stack frame. We'll see if that works.

Additional Links

DoStackSnapshot

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

How to debug a .NET profiler

Josef Biehler — Wed, 13 May 2020 06:54:19 +0000

In this article I just summarize shortly how you can apply what I've already written to profiler:

How to debug an unmanaged application with WinDbg

Josef Biehler ・ Apr 20 '20

#clr #debug #internals #windbg

Code example

I just copied the code from the last article. Our goal is to set a breakpoint in ProfilerCallback::ExceptionThrown in line 33. then we can inspect the parameter objectID. I will do this very quickly. If you want more information, go to the blog post I mentioned.

Howto

Add a Console.Read(); at the very beginning of the .NET test application. This gives us time to attach a debugger
Start app by executing start.bat
Start WinDbg & attach to process of TestApp
set breakpoint: bp DevToNetProfiler!ProfilerCallback::ExceptionThrown
enter g + enter to continue
enter any key in your TestApp
your breakpoint should be hit and you should see the source code:

go to View > Locals to list all local variables, including parameters:

How to debug Initialize()?

Let's say you want to debug the Initialize() method. The steps above won't work because if you attach to the running process, the Initialize() has already finished. But don't worry, this can be done with a few extra steps.

Adjust the `start.bat`

The key here is to expose the environment variables in the context where the TestApp is running. To do this you don't need to start the app directly from the batch file. So open start.bat and replace:



START TestApp/bin/Debug/TestApp.exe

with the path where the WinDbg.exe is on your PC:



START C:\Tools\WinDbg\windbg.exe

Start WinDbg

Execute the batch file. WinDbg should now appear.

Execute TestApp.exe

Go to File > Open Executable... and select TestApp.exe. WinDbg should immediately stop the execution:

Set a breakpoint

Do you remember the defered breakpoints I mentioned in my WinDbg blog post? As WinDbg stopped directly after TestApp was executed, nothing was loaded yet. So every breakpoint will be a defered one.

Enter the breakpoint:



bp DevToNetProfiler!ProfilerCallback::Initialize

And you should see this message:

Continue

Enter g + enter to continue the execution. In my setup, WinDbg stops again with this message:

We don't care about that message so let the app continue again. Now the breakpoint is hit:

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

IPC between C# and C++ by using named pipes

Josef Biehler — Sun, 03 May 2020 18:14:45 +0000

Note: Get the full working example here: Sample project

While writing my own .NET profiler I realized one problem: The profiler, written in C++, must be a DLL. If I want to provide a GUI, I want to do this with C# and WPF. How can both components, that share not the same memory, exchange data?

In a private project I used named pipes for inter process communication to let a NodeJS process communicate with a C# application so I decided to do the same with my profiler.

In this article, we build a small runnable example with two-way communication and a very very simple protocol.

Named vs anonymous pipes

I have chosen named pipes, because I want to setup a bidirectional channel. The pipe server (C# application) should be able to send a configuration to the pipe client (C++) and after this first data exchange, only the client is sending data.
Anonymous pipes are one-way only as stated by Microsoft.

Pipe Server (C#)

You have to use the class NamedPipeServerStream.

static void Main(string[] args)
{
  var namedPipeServer = new NamedPipeServerStream("my-very-cool-pipe-example", PipeDirection.InOut, 1, PipeTransmissionMode.Byte);
  var streamReader = new StreamReader(namedPipeServer);
  namedPipeServer.WaitForConnection();

  var writer = new StreamWriter(namedPipeServer);
  writer.Write("Hello from c#");
  writer.Write((char)0);
  writer.Flush();
  namedPipeServer.WaitForPipeDrain();

  Console.WriteLine($"read from pipe client: {streamReader.ReadLine()}");
  namedPipeServer.Dispose();
}

pipe name: Self explanatory
direction: I use InOut to be able to send something to the client
maxNumberOfServerInstances: This should be 1 if you have only one client. You must increase the value if you want to handle parallel clients. We will see this in action later on.
transmission mode: We are sending the data in a byte stream. This implies that the other side knows how many data should be sent. In our case we read until a line break occurs (client -> server) or a \0 byte is read (server -> client).
Flush(): Just tell the server, that it should clear it's buffer right now.
WaitForPipeDrain(): This causes the server and client to run serially by waiting for all bytes to be read.
Caveat: two lines above I'm sending (char)0. Please be aware of the cast! Without it, an integer is sent which means 4 bytes where all bits are set to 0. The receiver awaits only one zero byte and thus will not read the remaining three bytes. They will be left in the buffer which forces WaitForPipeDrain() to wait forever. The cast ensures that only one byte is sent.
ReadLine(): The client sends a string, terminated by \r\n. But you can build whatever protocol you want.

Pipe Client (C++)

Also very simple:

#include <windows.h>
#include <iostream>

HANDLE fileHandle;

void ReadString(char* output) {
  ULONG read = 0;
  int index = 0;
  do {
    ReadFile(fileHandle, output + index++, 1, &read, NULL);
  } while (read > 0 && *(output + index - 1) != 0);
}

int main()
{
  // create file
  fileHandle = CreateFileW(TEXT("\\\\.\\pipe\\my-very-cool-pipe-example"), GENERIC_READ | GENERIC_WRITE, FILE_SHARE_WRITE, NULL, OPEN_EXISTING, 0, NULL);

  // read from pipe server
  char* buffer = new char[100];
  memset(buffer, 0, 100);
  ReadString(buffer);

  std::cout << "read from pipe server: " << buffer << "\r\n";

  // send data to server
  const char* msg = "hello from c++\r\n";
  WriteFile(fileHandle, msg, strlen(msg), nullptr, NULL);
}

A few points that needs to be mentioned:

pipe name: On Windows, a pipe path must follow the naming convention: \\\\.\pipe\<pipe-name>. The dot is equal to localhost and can be replaced by remote server names. As a pipe is treated as a normal file, you have to specify the full path.
Access rights: When defining a two-way pipe, your client must request as well read as write rights.
String termination: As already seen in the server code, you must send \r\n at the end of the string. Of course, just a very simple "protocol specification".
Transmission mode: As stated in the official Microsoft documentation, by calling CreateFile the pipe client is initially in byte transmission mode.

Compile both projects, execute the server first, than the client and you should get this result:

Troubleshooting

If you have troubles in bringing both components together, there is an easy possibility to check if the pipe has been opened. Open a powershell window and type: get-childitem \\.\pipe\. This will print all open pipes:

Concurrent clients

In the example above we can only handle one client. Multiple clients would be possible if you close the server and reopen it again. But to allow concurrent clients, you must create multiple instances of NamedPipeServerStream. Raising the maxNumberOfServerInstances parameter to 5 will allow 5 parallel connections. Using a number of connections that is less than wished amount of parallel instances leads to the exception system.io.ioexception all pipe instances are busy.

A very simple and error prone solution would be:

var instances = new Task[5];
for (int i = 0; i < instances.Length; i++)
{
  instances[i] = Task.Run(() =>
  {
    var namedPipeServer = new NamedPipeServerStream("my-very-cool-pipe-example", PipeDirection.InOut, 5, PipeTransmissionMode.Byte);
    var streamReader = new StreamReader(namedPipeServer);
    namedPipeServer.WaitForConnection();

    var writer = new StreamWriter(namedPipeServer);
    writer.Write("Hello from c#");
    writer.Write((char)0);
    writer.Flush();
    namedPipeServer.WaitForPipeDrain();

    Console.WriteLine($"read from pipe client: {streamReader.ReadLine()}");
    namedPipeServer.Dispose();
  });
}

// don't do this except you know what you are doing
Task.WaitAll(instances);

Summary

I showed you in a quick and dirty example how you can communicate between a C++ and a C# component.

Additional Links

Microsoft Win32 documentation

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.

How does a .NET profiler work?

Josef Biehler — Sat, 02 May 2020 11:17:27 +0000

Get the code for this tutorial

Introduction

In the last article we built a small runnable example. To start just use the template we created there. If you don't have it yet, visit the article and download the base profiler project.

Create a .NET profiler with the Profiling API - Start of an unexpected journey

Josef Biehler ・ Apr 30 '20

#dotnet #debug #tutorial #cpp

Attention! Most of the functions that are used to query information from the profiler return a HRESULT. You should check if this value is 0 (error) or not. For the sake of simplicity I will omit all those checks because they make the code harder to understand. This counts for all following blog posts about this topic.

Profiler loading

As mentioned in the first post, the profiler is loaded along with the application. If the profiler is called, it is called by the application's thread. If multiple threads are running in your app and every thread triggers events, all those events arrive "at the same time" at your profiler in different threads. So you have to ensure that your profiler is threadsafe.

ICorProfilerCallback

Our profiler must implement that interface. Do you remember all those stubs we created? That are callbacks called by the CLR on certain events.

ICorProfilerInfo

The profiler should request an instance of type ICorProfilerInfo. This object is a bridge between the profiler and the profiled app. You can request the function name for a given function id for example. We will see some of it's power in the next articles.

Lifecycle

Well there are two functions that can somehow be identified as Lifecyclefunctions.

Initialize() is called after the CLR has initialized and loaded up the profiler. This is a very important point in time because it is the only place where you can setup the profiler.
Shutdown() is called when the application gets closed

Initialize

We will focus on Initialize because as already said, you must setup your profiler.
What you must do:

request an instance of type ICorProfilerInfo (or any newer version - you know, the numeric suffix)
set flags to tell the CLR which events you want to receive
maybe set some hooks (we will see this later)

Necessary steps:

add include <corprof.h>
add CComQIPtr<ICorProfilerInfo2> iCorProfilerInfo; variable to the outside of the class.
add pICorProfilerInfoUnk->QueryInterface(IID_ICorProfilerInfo2, (LPVOID*)&iCorProfilerInfo); to Initialize()

The include is required because it contains the definition of IID_ICorProfilerInfo2. The iCorProfilerInfo variable should not be an instance variable. This makes it much easier to handle. We need it later on to request metadata about the application.

Flags:

ICorProfilerInfo has a method SetEventMask(). You must pass a DWORD that reflects the events you want to be notified. A full list of all flags can be found here. In this example I choose COR_PRF_MONITOR_EXCEPTIONS because I want to monitor all exceptions that occur:

  iCorProfilerInfo->SetEventMask(COR_PRF_MONITOR_EXCEPTIONS);

The function now looks like this:

CComQIPtr<ICorProfilerInfo2> iCorProfilerInfo;
HRESULT __stdcall ProfilerCallback::Initialize(IUnknown* pICorProfilerInfoUnk)
{
  pICorProfilerInfoUnk->QueryInterface(IID_ICorProfilerInfo2, (LPVOID*)&iCorProfilerInfo);
  iCorProfilerInfo->SetEventMask(COR_PRF_MONITOR_EXCEPTIONS);

  return S_OK;
}

Depending on the flags you set you can use different callback methods (that are all those stubs we created in ProfilerCallback.cpp). In order to know which one you need, go the the documentation and search for COR_PRF_MONITOR_EXCEPTIONS:

ExceptionThrown Callback

We focus on the ExceptionThrown callback and fill it with some stupid logic:

HRESULT __stdcall ProfilerCallback::ExceptionThrown(ObjectID thrownObjectID)
{
  cout << "from profiler: \t\t\texception thrown\r\n";
  return S_OK;
}

Adjust the Program.cs of the test app and throw an exception:

static void Main(string[] args)
{
  try
  {
    throw new Exception();
  }
  catch
  {

  }

  Console.Read();
}

Now compile everything and execute start.bat:

Congratulations, you created your first profiler!

Threading

Let's see in which thread a profiler is executed. We keep the code from the sections above but adjust the ExceptionThrown callback a bit. I suggest to print the current thread id. This can be done by including <thread> and adjusting the message:

// ./code/DevToNetProfiler/DevToNetProfiler/ProfilerCallback.cpp#L31-L35

HRESULT __stdcall ProfilerCallback::ExceptionThrown(ObjectID thrownObjectID)
{
  cout << "from profiler: \t\t\texception thrown in thread " << this_thread::get_id() << "\r\n";
  return S_OK;
}

Also you should print the thread id in your C# app:

// ./code/DevToNetProfiler/TestApp/Program.cs#L8-L21

static void Main(string[] args)
{
  try
  {
    throw new Exception();
  }
  catch
  {

  }

  Console.WriteLine($"from app:\tthread id: {AppDomain.GetCurrentThreadId()}");
  Console.Read();
}

And this should be the result:

Both components have the same thread id.

Bitness

As always when dealing with native code, you must take the bitness into consideration. This is especially true if you want to use FunctionEnter/Leave callbacks.
The simple rule is: If the .NET app runs as 32Bit app, your profiler must be compiled as 32Bit profiler and vice-versa.

.NET and bitness

Read this article, if you want to read more about bitness in .NET and Visual Studio:

Know the bitness of your .NET application

Josef Biehler ・ May 1 '20

#dotnet #csharp #tutorial #environment

What happens if we ignore the bitness?

Let the profiler being compiled to 32Bit and set the TestApp to 64Bit. The message from the profiler is missing now:

Additionally we can find an error message in the windows event viewer:

Summary

This article showed the basics of a profiler. I think this is enough to get an insight. Do you miss some information that seems relevant to you? Let me know!

In the next articles I want to focus on some use cases. Stay tuned if you want to see some assembler code!

Found a typo?

Do not worry about merge conflicts. I will resolve them on my own.