MiniFilter InstanceSetupCallback is not called?

一般來說,MiniFilter 的 InstanceSetupCallback 會在 filter manager 把 minifilter attache 到 volume 後呼叫。如果沒有的話,可以檢查一下 minifilter 的 INF 是否把 instance flags 設定成 0x00000001 了:

  • 0x00000000: Allow all attachments
  • 0x00000001: Suppress automatic attachments

如果你的 INF 不是自己從頭寫的,而是參考 Windows Minispy 改來的,哪很有可能你沒有收到 InstanceSetupCallback() 的原因就是你忘了改掉 flags 值為 0。

;Instances specific information.
DefaultInstance    = "Scanner Instance"
Instance1.Name     = "Scanner Instance"
Instance1.Altitude = "265000"
Instance1.Flags    = 0x0          ; Allow all attachments

Written with StackEdit.

windbg cheet sheet

WinDbg Cheet Sheet

Launch program

$> windbg -y C:\sym -srcpath C:\src notepad.exe

Written with StackEdit.

Windows + Visual Studio + VSCode + CMake 的疑難雜症

Environment

  1. Windows 10
  2. Visual Studio 2019
  3. CMake 3.27.7
  4. VSCode
  5. VSCode CMake Tools

1. CMAKE_BUILD_TYPE 是空的

參考一下這篇的處理。
大致上因為 Visual Studio + CMake 並不會主動 set CMAKE_BUILD_TYPE,除非你直接呼叫 CMake 時帶上 -DCMAKE_BUILD_TYPE=Debug

cmake -DCMAKE_BUILD_TYPE=Debug path/to/source

不過都用 VSCode 了就是懶得 command line 了,只好再請出 settings.json:

{

    "cmake.configureSettings":  {
        "CMAKE_BUILD_TYPE":  "${buildType}"
    }
}

Written with StackEdit.

CMake + vcpkg + vscode

CMake + vcpkg + vscode

  1. CMake 3.27.7
  2. CMake Tools
  3. VSCode

安裝的部份就跳過了,使用 Windows 和 boost::filesystem 當例子。

Key takeaways

vcpkg

使用 manifest mode,不開 vcpkg global integration。在 workspace root 下產生 vcpkg.json

{
    "$schema":  "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
    "name":  "test",
    "version":  "0.1.0",
    "dependencies":  [
        "boost-filesystem"
    ]
}

CMake

修改 .vscode/settings.json 讓 CMake 可以使用 vcpkg。

{
    "cmake.configureSettings": {
        "CMAKE_TOOLCHAIN_FILE": "you-path-to-vcpk/scripts/buildsystems/vcpkg.cmake",
        "VCPKG_TARGET_TRIPLET": "x64-windows"
    }
}

CMake

find_package(Boost REQUIRED COMPONENTS filesystem)

if(Boost_FOUND)
    include_directories(${Boost_INCLUDE_DIRS})
    target_link_libraries(hello PRIVATE ${Boost_LIBRARIES})
else()
    message(FATAL_ERROR "Boost not found. Please install Boost.")
endif()

Troubleshooting

Boost Not Found

  1. 先清掉 CMake cache 試試看:如果過程中,已經反覆 CMake -G 過,可能受到 CMake cache 影響,導致 find_package(Boost, ...) 不會再重頭開始找。

  2. 修改 .vscode/settings.json已開啟 CMake find boost debug log,方法如下:

    {
        "cmake.configureSettings": {
            ...
            "Boost_DEBUG": "on"
        }
    }
    
  3. 放棄 vscode ,繞過 CMake tool extension 的部份。

Reference

  1. vcpkg in CMake projects

Written with StackEdit.

CMake + vcpkg + vscode

CMake + vcpkg + vscode

  1. CMake 3.27.7
  2. CMake Tools
  3. VSCode

安裝的部份就跳過了,使用 Windows 和 boost::filesystem 當例子。

Key takeaways

vcpkg

使用 manifest mode,不開 vcpkg global integration。在 workspace root 下產生 vcpkg.json

{
    "$schema":  "https://raw.githubusercontent.com/microsoft/vcpkg-tool/main/docs/vcpkg.schema.json",
    "name":  "test",
    "version":  "0.1.0",
    "dependencies":  [
        "boost-filesystem"
    ]
}

CMake

修改 .vscode/settings.json 讓 CMake 可以使用 vcpkg。

{
    "cmake.configureSettings": {
        "CMAKE_TOOLCHAIN_FILE": "you-path-to-vcpk/scripts/buildsystems/vcpkg.cmake",
        "VCPKG_TARGET_TRIPLET": "x64-windows"
    }
}

CMake

find_package(Boost REQUIRED COMPONENTS filesystem)

if(Boost_FOUND)
    include_directories(${Boost_INCLUDE_DIRS})
    target_link_libraries(hello PRIVATE ${Boost_LIBRARIES})
else()
    message(FATAL_ERROR "Boost not found. Please install Boost.")
endif()

Troubleshooting

Boost Not Found

  1. 先清掉 CMake cache 試試看:如果過程中,已經反覆 CMake -G 過,可能受到 CMake cache 影響,導致 find_package(Boost, ...) 不會再重頭開始找。

  2. 修改 .vscode/settings.json已開啟 CMake find boost debug log,方法如下:

    {
        "cmake.configureSettings": {
            ...
            "Boost_DEBUG": "on"
        }
    }
    
  3. 放棄 vscode ,繞過 CMake tool extension 的部份。

Reference

  1. vcpkg in CMake projects

Written with StackEdit.

StackEdit 測試

這是標題

This is a source code - of course - a C++ hello world.

#include <iostream>

int main( int argc, char* argv[] )
{
    std::cout << "Hello World" << std::endl;
    return 0;
}

看起來還不錯,真希望有 native editor 版本 …

Written with StackEdit.

auto + braced-init-list 在 direct initialization 和 copy initialization 中的差異

C++17 中有條修改 n3922 細想之後挺有意思的。 C++11 中規定,下面的程式碼會推導出一個 std::initializer_list<int>:
auto i{ 10 }; // i is a std::initializer_list<int>
當初在 C++11 看到時,覺得的確不太直覺,但當時記性還行,索性就記得說:新語言特性(auto)喜歡跟新語言特性(initializer_list)一起。後來在 C++17 中修改了,
For direct list-initialization:

1. For a braced-init-list with only a single element, auto deduction will deduce from that entry;
2. For a braced-init-list with more than one element, auto deduction will be ill-formed.
也就是說,C++17 後變成了: auto + direct initialization + braced-init-list 只能初始化單一一個變數。
auto i{ 10 }; // legal and i is a std::initialize_list<int>
auto i{ 10, 11 }; // illegal
岔題一下:auto + direct initialization + braced-init-list 沒辦法用在 C-style array 上,所以下面在 C++11 和 C++17 都是非法的。
auto array[]{ 10, 11 }; // illegal
auto array2[ 2 ]{ 10, 11 }; // illegal
但如果今天場景變成 auto + copy initialization + braced-init-list 那就總是會定義出一個 std::initialize_list<int> 變數了。
auto i = { 10 }; // legal and i is a std::initializer_list<int>
auto array = { 10, 11 }; // legal and array is a std::initializer_list<int>
哎,那這次要怎麼記得這件規則呢?顧名思義:等號右邊是 braced-init-list ,所以它原本就是 std::initialize_list<int> ,那既然是 copy initialization 。那就連型別也一起 copy 吧~真是太哲學了! 好吧,因為是哲學,所以有點不太科學:return value 可以視為一種 copy initialization ,但這情況下,是不能使用 auto 推導出 std::initialize_list<int> 的,因為 braced-init-list 不是一個 expression ,並不會產生一個 value [1] 。因此 return type 需要一個明確的型別來搭配,並用來呼叫 return type 的 constructor 的 ...
auto f()
{
    return {1,2}; // ill-formed, {1,2} is not an expression
}
...

Use bu in WinDbg and get `Couldn't resolve error at module!func`

在 WinDbg 中設定 breakpoint 時如果遇到 symbol mismatching ,那 WinDbg 就會提示 Couldn't resolve error at module!func 。不過有趣的是,如果今天是用 bu module!func 也遇到一樣的問題,那還會是 symbol not found 嗎?如果此時 stack 是停在 nt!DebugService2 時,那就很有可能也是 symbol not found 了。
0: kd> bu module!func

0: kd> g
Breakpoint 0's offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt!DebugService2+0x6:
fffff806`31805296 c3              ret

1: kd> k
 # Child-SP          RetAddr           Call Site
00 ffffde00`16226b68 fffff806`31771955 nt!DebugService2+0x6
01 ffffde00`16226b70 fffff806`317718e7 nt!DbgLoadImageSymbols+0x45
02 ffffde00`16226bc0 fffff806`31b558f1 nt!DbgLoadImageSymbolsUnicode+0x33
03 ffffde00`16226c00 fffff806`31b55423 nt!MiDriverLoadSucceeded+0x18d
04 ffffde00`16226ca0 fffff806`31b54c06 nt!MmLoadSystemImageEx+0x807
05 ffffde00`16226e40 fffff806`31b3800c nt!MmLoadSystemImage+0x26
06 ffffde00`16226e80 fffff806`31b36f22 nt!IopLoadDriver+0x23c
07 ffffde00`16227050 fffff806`31b36c32 nt!PipCallDriverAddDeviceQueryRoutine+0x1be
08 ffffde00`162270e0 fffff806`31b365f0 nt!PnpCallDriverQueryServiceHelper+0xda
09 ffffde00`16227190 fffff806`31b35d83 nt!PipCallDriverAddDevice+0x41c
0a ffffde00`16227350 fffff806`31b2fcc6 nt!PipProcessDevNodeTree+0x333
0b ffffde00`16227420 fffff806`3176efba nt!PiRestartDevice+0xba
0c ffffde00`16227470 fffff806`3168e5c5 nt!PnpDeviceActionWorker+0x46a
0d ffffde00`16227530 fffff806`317265f5 nt!ExpWorkerThread+0x105
0e ffffde00`162275d0 fffff806`318048d8 nt!PspSystemThreadStartup+0x55
0f ffffde00`16227620 00000000`00000000 nt!KiStartSystemThread+0x28

1: kd> bc *

1: kd> bu module!func
Couldn't resolve error at 'vmodule!func'

為什麼呢?此時不是使用 Set Unresolved Breakpoint 嗎?嗯嗯,Unresolved Breakpoint 也是有需要 resolve 的時候,剛好系統正在載入新 module ,而且符合 bu 指定的 module name ,那就會開始 resolve symbol name ,如果找不到一樣會跳出 Couldn't resolve error at 'vmodule!func' 了。

boost.test BOOST_CHECK_EXCEPTION 竟然不支援 lambda

如題 BOOST_CHECK_EXCEPTION 竟然不支援用 lambda 寫 predicator ...
	
    BOOST_CHECK_EXCEPTION(
        p.parseString("---\n---"),
        durin::yaml::ParserException, 
        []( const durin::yaml::ParserException& ex ) {
        	return ex.what() == std::string( "Double DocBegin" );
        });
	
Feel so sad ...

KDE Craft 初試

雖然越來越多的 web-based UML editor 可以用,而且感覺 portability 也不錯,不像 native editor 可能還會被綁死在特定 file format 上,不過怎麼說呢?細節上的操作性還是有差,以前工作 Windows only ,用還是 open source 版本的 StarUML 也是挺愜意的,但隨著 MacOS, Linux 近來攪和後,就屬意了 Umbrello ,只是好像有時候不是很穩定,想來自己貢獻一下,沒想到 KDE 貌似就有兩套 build tool,craft 和 kdesrc-build ,太折騰了… craft 用 python 寫的,比起 kdesrc-build 用 perl ,那還是玩玩看 craft 吧,沒想到還是要用到 python27 Orz ...

Native Blog Editor

唉唉,2021都要結束了,找個 blog friendly 的 native editor 還是很困難,應該說從來沒簡單過,加上又是一個時代的結束…

Mismatch between lldb and clang on vscode

Mismatch between lldb and clang on vscode

奇怪,今天嘗試在 vscode 中使用 lldb live debug 一個 C++ 程式,斷點下好後卻卡住了。

Console 的錯誤訊息是:bind: Invalid command `enable-meta-key’.

上網查了一下,貌似 vscode、 QtCreator 都有災情。

  1. https://github.com/vadimcn/vscode-lldb/issues/141
  2. https://bugreports.qt.io/browse/QTCREATORBUG-21615

追了一下才發現,自己的環境有兩份 clang ,分別是 6.0 和 8.0 。單純抄 vscode + C/C++ 的官方文件可能會導致 compiler 和 debugger 的版本不合,另外 miDebugerPath 似乎也要更新成使用 lldb-mi 版本,不然會有以下錯誤。

warning: ignoring unknown option: --interpreter=mi
warning: ignoring unknown option: --tty=/dev/pts/19

最終可用環境是:
ubuntu Ubuntu 18.04.1 LTS
vscode 1.42.1
C/C++ Extension 0.26.3
lldb 8
clang 8

{
    "MIMode": "lldb",
    "miDebuggerPath": "/usr/bin/lldb-mi-8"
}

vscode menu bar 修改

kde neon 上的 vscode 貌似在自動更新後,native menu bar 的字體顏色變得跟 native theme 的顏色太接近,人眼幾乎沒辦法看出字來。
模糊的 menu bar調整了一下系統的 theme或是調整 dark mode 都沒有用。好在 menu bar 可以改成 vscode 自己畫。

  1. File > Preferences > Settings (or Ctrl+Shift+P > Preferences: Open Settings (UI))
  2. 用 window.titlebarbarstyle 當作 search settings 的關鍵字。
  3. 將 native 改成 custom,重開 vscode 就好了。

Reference

  1. Change Visual Studio Code’s title bar color

2020

復活吧,我的 blog

LLVM for Windows Visual Studio 2010/2012

Chandler Caruth 在 GoingNative 2013 上宣布了一個好消息,LLVM 3.4 (開發中)正在如火如荼地移植到 Windows 上,目前初步的成果已經可以使用 Visual Studio 2010/2012 作為 IDE 了,對於習慣 Visual Studio 的人來講應該是個好消息。

alpha 版本可以在這邊下載到:

  • SVN Snapshot: http://llvm.org/builds/
  • 設定上也非常簡單,在 Project > Properties > General > Platform Toolset 改成 LLVM-vs2010 即可。
    llvm_on_windows

試玩了一下發現:

新 project 有感

C# + .NET framework 2.0 + Visual Studio 2010 + remote debugging = 殘廢

C# + .NET framework 2.0 + dump + WinDbg = 悲劇

NetBSD Kernel 要支援 Lua

讓我想起了以前微軟研究院利用 C# 改良版 Spec# 開發的 Singularity OS ,不過這次換成了 Lua 。

2010 年便開始開始的 GSoC project,一度變成沒人維護的項目,不過 NetBSD 7 可能即將包含它。還提到了 Python 和 Java 也是有可能的取代方案,不過考慮到這兩個語言的 object mapping 和 memory 需求量,還是沒有成真。

目前看來外國鄉民是一面倒地不看好,不過技術嘛,或許會有令人驚豔的應用或影響出現也說不定!不過 script language 大都帶有 garbage collection ,要讓這大傢伙和 kernel 裡其他的 subsystem 互動順利、尤其是記憶體管理,加上處理 interpreter 內,自帶的 synchronization mechanism 搭配 kernel scheduler ,花的功夫應該是不少,令人好奇!

News http://bsd.slashdot.org/story/13/02/16/2329259/netbsd-to-support-kernel-development-in-lua-scripting

Slides: https://fosdem.org/2013/schedule/event/lua_in_the_netbsd_kernel/attachments/slides/278/export/events/attachments/lua_in_the_netbsd_kernel/slides/278/kernel_mode_lua.pdf

BoostPro 要關門了?!

在 Boost mail list 上看到的消息:

http://lists.boost.org/Archives/boost/2013/01/200634.php


Subject: [boost] Future of Boost Windows Installers
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-01-31 14:42:33

Hi,

As many of you already know, I'm going to work at Apple in late
February, and BoostPro is closing its doors. For many years, the Boost
Getting Started Guide has suggested that Windows users pop over to
BoostPro's website and use the latest installer to get Windows binaries.
We'd like to donate to the community the technology used to build those
installers. If anyone would like to pick up the job of creating them,
we'd be happy to offer guidance.

Right now I'm on a plane where an uplink to GitHub is creeping along at
4KB/s, so I've been pushing the stuff up in bits and pieces and the
latest stuff isn't up there, but it's going to
http://github.com/boostpro/installer and will be complete within 24 hours.

Whatever happens with this installer code, someone is going to need to
update the Getting Started Guide, either to point at the installer's new
home, or to remove references to it.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost

BoostPro 是幾位 C++ 大師組成的教學顧問團隊,BoostPro 上有他們的黃金陣容的介紹:

  • Dave Abrahams
    多年來致力於 C++ 標準制定和 Boost 推廣維護,貢獻了很多 Boost libraries、2001 年創辦 BoostPro 、
  • Joel de Guzman
    Boost.Spirit 、 Boost.Fusion 和 Boost.Phoneix 的作者。看過 Spirit 精妙的 C++ expression templates 魔術後,很難不對作者留下深刻印象。
  • Jeremy Siek
    六個 Boost libraries 的作者,很早就在 Boost 裡頭提供一套 concept check 的人。

嗯, Apple 這幾年應該算是最力挺 native code 的大型軟體公司(硬體公司?!),旗下的 LLVM、Clang 等 open source projects 不說,還雇用了 Doug Gregor (Modules for C++)、Howard Hinnant(libcxx 作者) 等神人在為更底層的基礎扎根,曾幾何時,竟然要喊聲: Apple 加油啊~

MiniFilter InstanceSetupCallback is not called?

一般來說,MiniFilter 的 InstanceSetupCallback 會在 filter manager 把 minifilter attache 到 volume 後呼叫。如果沒有的話,可以檢查一下 minifilter 的 INF 是否把 instance fla...