amirul

Pool corruption — может быть кто угодно (в том числе и железо). Кто-то испортил (фактически записал поверх) служебные структуры менеджера памяти, а багчек случился только после того, как мемори менеджер попытался эти структуры использовать (в данном случае ExDeferredFreePool).

Погонять memtest для успокоения совести.
Дальше verifier.exe

Create standard settings -> Select drivers from the list (выбрать все не-Microsoft драйверы)
Перегрузиться и ждать. Special pool в подавляющем большинстве случаев ловит любителей записывать по непринадлежащим им адресам прямо в момент записи (и в этом случае виновник будет прямо на стеке).

ntoskrnl.exe!KeAcquireSpinLockAtDpcLevel

Ну это точно НЕ САМА Visual Studio. Предположительно какой то сильно умный фильтр/минифильтр (возможно антивирус: типа ему нужен процессор чтобы проверить сигна). Попробуйте собрать профайл трейс со стеками и посмотреть кто эти самые спинлоки захватывает.

Если у сервера есть tlb (он бы все равно понадобился при подключении референса в проект), то tlbimp в помощь. Если же tlb нет (ни отдельного ни встроенного), то здесь только в рантайме типы создавать (можно вместо CLSID пользоваться и ProgID, если есть), а потом эти типы активировать

Виза отличается от H1. Principal applicant-у (тому у кого на руках оффер) дают W1 — с привязкой к работодателю. Dependent-ам дают W2 — право на работу без привязки к работодателю (в отличие от американского аналога — H4, по которой работать нельзя).

Сама виза не является, собственно, воркпермитом. Пермит — это бумажка, которую встепливают при первом въезде по этой визе прямо на границе (если пройдешь собеседование с border officer-ом :-) ). При этом без пермита виза все еще продолжает действовать как Multiple Entry виза (типа американской B1/B2).

ВО для работы не нужно, но весьма пригодится, если вдруг захочется запарковать трактор в канадских снегах.

> всё кроме изменения разрешений и смены владельца
У администраторов по умолчанию есть SeTakeOwnershipPrivilege, то есть они могут открыть любой объект с WRITE_OWNER доступом. У владельцев объектов всегда есть неявный allow WRITE_DAC доступ, то есть они могут менять разрешения на свои объекты независимо от того, есть ли это allow (или даже deny) ACE на WRITE_DAC.

Короче, нужно сначала «овладеть» объектом (вкладка Owner в Advanced security диалоге или takeown.exe если Вы предпочитаете командную строку). А уж потом можно менять доступ на что угодно.

Если сильно хочется после этих манипуляций можно вернуть владение TrustedInstaller-у.

В XP только костыли. Искать так
В частности скрипт, нажимающий на кнопки или более ошибкоустойчивый подход с изменением самого файлы. Я бы посоветовал вытащить скрипты (и создаваемые объекты) из unSolicitedRCUI и засунуть все в отдельный скрипт.

www.bing.com/search?q=scancode+map

Не надо драйверов. Practical Windows Sandboxing в трех частях. ACL-ей хватает с головой для ограничения практически всего (в том числе и виндового нетворкинга — пайпов и мейлслотов, для berkeley sockets придется использовать встроенный файрвол) — собственно для подобного контроля доступа они и были придуманы.

Хромовская песочница — довольно независимый от остального хрома проект. Так что можно вытащить и использовать в личных целях.

Создал c:\test.ps1 следующего содержимого:

powershell -noexit "echo $args"

Добавил в HKCU\...\test\command\@ следующее:

C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -EP Bypass -File C:\test.ps1 "%1"

Никакой разницы при запуске для exe и остальных файлов не заметил. Вообще говоря более правильный способ передачи параметров в скрипты — указание param блока.

test.ps1:

param($FilePath)
powershell -noexit "echo $FilePath"

HKCU\...\test\command\@:

C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe -EP Bypass -File C:\test.ps1 -FilePath "%1"

Port sharing — это одно из применений более общей технологии HTTP API

Если выполнить
netsh http show servicestate

то можно увидеть, кто и на какие url-ы подписан в данный момент. Это если вообще независимое приложение, которое можно запускать хоть от пользователя, хоть из другого сервиса.
Но если хочется, можно написать и ISAPI плагин для IIS.

Как-то так:

$srcPath = ".\Pictures"
$shrinkBy = New-Object Drawing.Size 1, 1
foreach ($file in dir -r -inc *.jpg, *.jpeg, *.png, *.gif $srcPath) {
    echo $file.FullName
    $src = [Drawing.Image]::FromFile($file)
    $dest = New-Object Drawing.Bitmap $src, ($src.Size - $shrinkBy)
    $format = $src.RawFormat
    $src.Dispose()
    $dest.Save($file.FullName, $format)
}

Сохраняет изменения прямо в исходный файл (лень возиться с воссозданием структуры директорий), так что лучше работать с копией.
Перепаковка с дефолтными параметрами энкодера. Если нужны другие — можно повозиться с перегрузкой Save.
Для смены параметров интерполяции придется создавать Drawing.Graphics и рисовать туда.

Вообще то очень странная статья. Единственный правильный совет «Find bottlenecks» задвинут на предпоследнее место, но при этом используется Resource Monitor вместо WPT Kit.
Отключать автозагрузки и сервисы стоит после того, как обнаружено их негативное воздействие на производительность. Иначе не имеет смысла (более того, можно чего нибудь сломать). Удалять шрифты и игры — глупость. Игры с суперфетчем без понимания происходящего могут только ухудшить производительность. Отключение звуков — это вообще что то новое в «твиканьи». Отключать dwm не надо — это D3D приложение, которое использует видеокарту только тогда, когда никто другой ее не использует. И т.д.

Намертво и при этом на многопроцессорной машине. Если это как то и связано с диском, то скорее всего какой то драйвер блокирует все ядра в ISR или DPC. Но это может быть и чего нибудь связанное со спинлоками (что более вероятно, ибо нечто подобное у меня наблюдалось с проактивной защитой аутпоста пару лет назад — снес к чертям как только вычислил).

Собственно, искать гада стоит начинать с установки WPT Kit
Так как проблема появляется нечасто, то придется постоянно крутить circular logging. Запускаем из elevated консоли:

xperf -on latency -stackwalk profile -maxfile 128 -filemode circular

Естественно, некоторая часть ресурсов будет отъедаться на постоянную запись лога, но по личным наблюдениям оно не особо мешает даже на относительно слабом low-middle end ноуте более чем двухлетней давности.
После того, как проблема зарепродюсится, нужно запустить из элевейченной консоли:

xperf -d trace.etl

Потом делаем

xperf trace.etl

для открытия лога и можно приступать к анализу. Первым делом стоит найти проблемный участок и сделать zoom на него. После этого прописать в символах

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

и вывести «Summary table» на «Stack counts by type». С очень большой вероятностью можно будет обнаружить странности уже там.
Также стоит взглянуть на «Summary table» для «DPC CPU Usage» и «Interrupt CPU Usage». Вообще говоря полуофициальное требование к длительности ISR — не более 10 мкс, DPC — не более 25 мкс. Средние значения длительностей ISR и DPC должны быть близки к этим, пиковое значение может быть в районе миллисекунд или даже десятков миллисекунд. Если там сотни-тысячи — это уже проблема.

В общем, удачной охоты.

Я могу только поддержать PowerShell (можно при необходимости установить и в XP, но лучше все же проапгрейдиться). Из WSH можно использовать CDO.Message