跳到主要內容

Export DLL Symbols

終於可以開始 debug DLL project 了!

之前根據 Debugging DLL Projects 的設定,
設定好 debug property 的 caller 並且在 DLL project 裡面設定中斷點,
但是 caller 一被叫起來後,馬上就 exit code 1,
並沒有 hit 到在我在 DLL project 裡設定的中斷點.

原本以為可能是我設定的中斷點不是 entry point ,程式提早結束所以沒有 hit 到.
想一想拿 sample code build 出來的 DLL 去測試,發現 entry point 是對的,
DLL debug 的中斷點在 sample code project 裡面也可以正常的 hit 並且停止.

想了很久後再看一次 caller 的文件,發現可以提高 caller 的 debug level ,
所以可以驗證我的另一個猜測,看是不是我指定的 DLL 其實並沒有被載入?
結果 debug log 顯示, DLL 應該是有被正確載入.
但是為什麼 caller log 會一直顯示載入 entry point function 失敗呢?

突然想到,我的 DLL 真的有 export 該 function 嗎?
Dependency Walker 去分析我的 DLL ,
發現 x86 build 確實有 export function,但是 x64 build 卻是空白的?
這時候我開始想說,難道是 build configuration 有問題?
但是 x86 build 的 DLL caller 也是無法正確載入啊?
那先不管 x64 build 好了,感覺 x86 build 比較有機會突破阻礙.

那再來比較 x86 build export 的 function 和 sample code 的有什麼不一樣
仔細一看,原來是 function name 被 mangling 處理過,多了 "_" prefix.
設定好 DLL project 的 def 檔重 build 後, caller 果然可以載入成功並且 hit 中斷點.
而神奇的 x64 DLL export function 是空白的現象也恢復正常了!

原來要 build 一個 DLL 有這麼多眉角要注意,學到這些東西很開心 :)


留言

這個網誌中的熱門文章

3M UVA3000 更換濾芯紫外線燈匣

用了一年的3M濾水器提示說要換濾芯和燈匣 上 Youtube 想找教學的影片可是沒看到 UVA 3000 的 經過了一番奮戰後在這邊記錄一下 希望可以幫助後人,以免再重蹈覆轍。 Step 1. 拔掉插頭,把淨水器從牆上拿下來(基本上他是掛著而已),比較方便施工。 Step 2. 把前蓋往上拉,很容易就可以看到裡面的東西了。 Step 3. 打開後可以看到有兩個柱狀體,左邊的是燈匣,右邊的是濾芯。 Step 4. 這裡有個祕技是,這兩個柱狀體是可以往上 翻開30 度左右,這樣就可以有比較大的空間施工。 Step 4. 更換濾芯的話,柱狀體的瓶身上有箭頭,往左就是轉開,往右就是鎖緊。 Step 5. 更換燈匣的話比較麻煩一點,因為他底部是電源,頂部的右邊有個突出來的小方塊。對照淨水器上方連接處的話會有個弧形的凹槽,這是要 match 的.如果你只注意瓶身的箭頭往右鎖回去,就會造成漏水...Orz... Step 6. 把前蓋蓋回,機器掛回牆上,插插頭,開水,如果機器沒有告訴你有燈匣異常或漏水的話,就可以長按 C / UV  Reset 計數器了. 所以關鍵字就是,要往上翻 30 度,燈匣上面的小凸點要在右側,要看瓶身的 小箭頭. May it helps!

Access private API gateway from another account

最近在做一個 PoC 驗證說怎麼在現有的架構下,把一些 public API 移到 VPC 裡面,只讓特定網路的人可以存取。 當然最直覺的想法就是,建一個新的 VPC ,加上 execute-api VPC endpoint 然後這個 VPC 再跟特定網路做 Peering,建一個 Private API Gateway 在新的 VPC 裡面。 這樣新的 VPC 可以透過 VPC endpoint 去存取 API Gateway,然後再加一個 ALB ,裡面的 target group 指向 VPC endpoint 的 IP和 443 port,ALB 設定好 Domain Listener,API Gateway 也加上相同的 Custom Domain Name,這樣子 ALB 就可以當成特定網路 access 的 entry point,一但 Peering 完成後,從特定網路來的 request 就可以經由 ALB -> API GW 跨 VPC 存取原本環境的 backend resource。 但我一直在想,Peering 是必要的嗎? 沒想到隔天就看到這個教學  How can I access an API Gateway private REST API in another account using an interface VPC endpoint?  裡面的做法突破了原本我直覺上的盲點! 就是即使是 Internal API Gateway 似乎只要設定好了 resource policy 就可以允許其他 account 的 VPC endpoint 跨帳號存取! 所以例子裡面的 private API Gateway 是建立在 B 帳號裡面,A 帳號的 VPC 只是啟用了 VPC endpoint,一但 B 帳號的 private API Gateway 在 resource policy 設定好允許 A 帳號的 VPC endpoint 存取,即使兩個帳號之間沒有 peering 也是可以互通的! 雖然說這樣子要帶 hostname header or api-gw-id 但是 原本架構上的 ALB 也是為了 VPC endpoint 可以知道要 forward request 給哪個 API Gateway ...

Application Load Balancer lambda endpoint healthy check will be charged

AWS 還是有蠻多坑的... 如果 ALB 的 TargetGroup 使用 lambda endpoint 那麼為了避免 code start issue 可能會使用 provisioned concurrency 另外 lambda endpoint 在 update stack 的時候會出現 Load Balancer not able to stabilizied 的問題。AWS support 目前給的work around就是開啟 ALB healthy check 預設是每 35 秒會做一次 healthy check 然後如果 ALB 跨3個 AZ 的話,healthy check count 就 x3 .... 然後每次的 lambda execution 都是照 lambda function usage 來收費 另外ALB的 healthy check 不會有完整的 request header 如果你的 framework 不預期有這種不正常的 header 沒有去 handle 的話 可能會一直狂噴500... 如果你還沒有把預設的 lambda error retry 關掉的話...... 這樣子用 lambda endpoint 真的比較省嗎?....