Определение разрядности работающего процесса

Периодически тредуется код который сможет определить разрядность процесса по его id. Вот пример такого кода:

[DllImport("kernel32.dll", PreserveSig = true, SetLastError = true, ExactSpelling = true)]
private static extern unsafe bool _IsWow64Process(void* hProcess, out bool wow64Process);

private static bool IsWow64Process(Process process)
{
  if (process == null)
    throw new ArgumentNullException("process");
  if ((Environment.OSVersion.Version.Major == 5 && Environment.OSVersion.Version.Minor >= 1) || Environment.OSVersion.Version.Major >= 6)
    unsafe
    {
      bool retVal;
      if (_IsWow64Process(process.Handle.ToPointer(), out retVal))
        return retVal;
    }
  return false;
}

public static string GetPointerSize(int processId)
{
  using (Process p = Process.GetProcessById(processId))
    if (IsWow64Process(p))
      return 4;
  switch (IntPtr.Size)
  {
  case 4:
    return IsWow64Process(Process.GetCurrentProcess()) ? 8 : 4;
  case 8:
    return 8;
  default:
    throw new ApplicationException("Unknown pointer size");
  }
}

Attach особенности реализации

Неприятной особенностью интерфейса ICLRMetaHost является то, что поодерживаются только процессы с той же разрядностью, что и у вашего приложения. Другими словами если ваше приложение 64 бита, то и работать вы сможете только с 64-х битными процессами, а если 32 бита, то - только с 32-я битными.

О важности default значений

Забавная ситуация происходит, пользователи нам пишут что dotTrace Performance 4.0 работает медленно. С другой стороны многие ли позователь имеют ясное и четкое представление о том чем отличается sampling профиляция от tracing? Понимают ли пользователи, что один вид профиляции принципиально сильно быстрее или медленнее другого и почему это так?

Смена семантики COR_PRF_ENABLE_STACK_SNAPSHOT

В .NET Framework v2.0 флаг COR_PRF_ENABLE_STACK_SNAPSHOT входил в группу COR_PRF_MONITOR_IMMUTABLE (флаг можно устанавливать один раз и только во время вызова ICorProfilerCallback::Initialize), а в .NET Framework v4.0 уже входит в группу COR_PRF_ALLOWABLE_AFTER_ATTACH (этом флагом можно манипулировать в любое время). Собственно напоролся на это.

Несколько слов о пищеварении профайлеров

Получилось так, что главным заказчиком dotTrace стал ReSharper. А все потому что ReSharper очень серьезное и тяжелое приложение и не каждый профайлер способен проглотить в tracing/line-by-line режимах такой кусок мяса кода и в добавок выжить после такого издевательства.

На сегодня нашим классическим тестом на выносливость является: профиляция процесса загрузки солюшена ReSharper 5.1/6.0 под Visual Studio 2008/2010 с установленным релизным ReSharper 5.1. Перед началом теста все кэши стираются. Расширенный тест предполагает, что после загрузки солюшена запускается анализ солюшена на всю ночь (желателен пустой 500Gb HDD для нашего снапшота).

Недоделки которые сильно портят мнение пользователя о продукте

К моему глубокому сожалению поддержка профайлера в .NET Compact Framework v3.5.7283 содержит серьезную ошибку, которая увы делает невозможным корректную профиляцию в tracing режиме, если в коде кидаются exception которые не ловятся в той же функции где возникают. Как выяснилось причина в том, что необходимые нам нотификации из ICorProfilerCallback::ExceptionXXX просто не приходят. Получается, что наш продукт не виноват, но пользователю-то все равно кто виноват, программа же не работает. Обидно...

О культуре работы с реестром

Хотел озвучить одну вещь, которая меня крайне раздражает в некоторых программах, а именно нежелание за собой чистить реестр после деинсталляции и после окончания работы. На днях очень тесно столкнулся с этим. У пользователей наш dotTrace переставал нормально работать сразу после использования сторонних профайлеров (однозначно это было замечено за YourKit и ANTS от RedGate).