跳到主要內容

搜尋此網誌

Gelis 技術隨筆-部落格

發表文章

目前顯示的是 2月, 2012的文章

搬家公告

取得連結
Facebook
X
Pinterest
以電子郵件傳送
其他應用程式

現在 Gelis 新的文章會以點部落的為主，下面為新的網址： http://www.dotblogs.com.tw/gelis/ 兩處新舊文章都歡迎各位能夠多多支持。感謝各位啦 :)

閱讀完整內容

技術提供：Blogger

Gelis Wu. 版權所有

Gelis 技術隨筆-部落格: 關於我姓名：Gelis Wu 目前任職：.NET技術顧問我熱愛軟體工程、UML 系統分析與設計，擅長 OO 物件導向分析與設計外，也擅長將看似與程式碼無關的 OOA 與 OOD 的設計模型推導為實際程式碼設計，專精於 .NET 平台網頁 ASP.NET Web Form 與 MVC 開發與 WinForm 開發，領域包含了 WinForm、WPF 等。主要負責軟體開發架構、流程的導入的顧問工作，主要核心價值在於在導入適當的開發平台 Platform 框架 Framework，配合 (Team Foundation Server, TFS) 產品與 ALM 的Scrum 流程，搭配自動化 Code-Review 並結合 Team Build 進行自動化測試，自動化部署 (Continuous Deployment, CD)，並達到持續整合 (Cintinuous Integrated, CI)，以提升開發團隊的效率與價值。

封存

2024 6
- 10月 1
- 9月 2
- 3月 1
- 1月 2

2023 7
- 10月 1
- 8月 1
- 7月 2
- 6月 1
- 4月 1
- 2月 1
2022 3
- 8月 3
2021 9
- 11月 1
- 10月 3
- 9月 1
- 6月 1
- 5月 1
- 4月 1
- 1月 1
2020 9
- 12月 2
- 10月 1
- 9月 1
- 8月 2
- 5月 1
- 3月 1
- 1月 1
2019 12
- 12月 2
- 8月 1
- 6月 1
- 4月 5
- 3月 2
- 1月 1
2018 6
- 11月 1
- 10月 1
- 7月 2
- 6月 1
- 1月 1
2017 10
- 11月 1
- 9月 1
- 6月 1
- 5月 2
- 4月 5
2016 11
- 9月 6
- 8月 1
- 6月 1
- 2月 3
2015 15
- 12月 10
- 11月 1
- 8月 2
- 6月 2
2012 1
- 2月 1
  - 搬家公告
2011 3
- 3月 1
- 2月 2
2010 19
- 12月 1
- 11月 2
- 10月 4
- 9月 2
- 8月 2
- 7月 2
- 5月 1
- 3月 1
- 2月 4
2009 10
- 12月 3
- 6月 1
- 5月 1
- 3月 1
- 1月 4
2002 4
- 5月 1
- 3月 1
- 2月 2
2001 3
- 12月 1
- 10月 1
- 5月 1

顯示更多顯示較少

標籤

.NET Core
.NET Framework
.NET Standard
系統分析
系統分析師
系統設計
敏捷 (Agile)
軟體架構師
軟體架構設計
碎碎念

顯示更多顯示較少

檢舉濫用情形

FB 粉絲專頁

Gelis 的程式設計訓練營

有需要任何下方
（實體課程／企業內訊）可與

Gelis 程式設計訓練營聯繫

或者透過臉書 Messenger 與我聯繫

或連繫我的臉書社群【軟體開發之路】

近期課程

跨平台的 API Framework 框架設計V2（第二梯）

線上課程

New-單元測試 Unit Test 與 Moq 物件實務課程

決戰OOAD系列課程-使用UML (線上課程)

如何利用範本精靈 (C# Project Template) 簡化重複開發工作

第二波 - 早鳥優惠持續中

https://hiskio.com/courses/192?promo_code=VEQQMEY

先前(歷史)實體課程

單元測試 UnitTest 與 Moq 物件實務課程

跨平台的 Web API Framework 框架開發（第二梯）

ASP.NET Core 2.1 從入門到進階

決戰 OOAD 系列課程 - 使用 UML (第二梯)

Facebook 名片貼

建立你的名片貼

追蹤者

上個月的網頁瀏覽數次數

熱門文章

軟體工程師 - 成長的 10 個階段

軟體工程師 - 成長的 10 個階段前言先前，我在 Study4 小聚 #6 分享的一場關於軟體工程師 & 架構設計的養成之路，在該議程中，我分享了軟體工程師的 10 個階段（你的階段如有雷同、應該是...純屬巧合。XDDD）哪 10 個階段？我將軟體工程師的成長依序分為 10 個成長階段，因為隨著技能的提升，你該擴充的不會只是只有軟體開發技術，溝通與協作能力尤其重要，也像是『康威定律』中所提到的，你的軟件的設計 & 或系統設計本質上反映了企業的組織機構。系統各個模塊間的介面的設計，也反映了企業各個部門之間的信息流動和合作方式，這些技能再進行軟體架構設計時也息息相關，團隊在進行模組設計時需要頻繁的溝通，這些、都是是否能將軟體做好的關鍵因素。如 Logo 圖片，我依序說明每個階段的成長歷程。 1). 初始開發階段、熟悉 Programming/Developer 階段（PM/PO/SD 給規格後加以實作出來），並能夠藉由模仿來學習。這是剛進入軟體產業的學習階段。 2). 此階段代表已懂得透過重構來讓程式碼有基本的可維護性、已能熟用 DRY (Don't Repeat Yourself)，進入這個階段代表已經有基本的程式語言的基礎，應付 Programming/Developer 日常工作上的需求基本上沒什麼太大的問題。 3). 這裡的專案收尾代表對於專案開發已經有某些程度的認知、掌握度。我所提的掌握度在於了解『技術債』的產生緣由與危害，在 Programming/Devloper 層面懂得透過 S.O.L.I.D./Design Patterns 解決問題並開始能夠自我學習 + 自我成長。 4). 我這裡用『紀錄』代表能運用所學 + 將使用者需求運用〔邏輯思考〕與〔抽象化〕轉化為程式碼 + 並能自我成長將經驗保存下來。我認為這是跨越只是（寫程式／實作）進入另一個門檻的重要經驗與歷練。這個階段花費的時間會較長一點，時間長短取決於個人歷練、經歷、學習的環境與工作內容。 5). 此階段含括上面所有技能，並能夠與〔團隊〕和〔客戶〕溝通與協作、並產生出〔產品〕。而所謂的協作代表，不只自身技術所長能應付本身開發工作工作所需，亦能帶領團隊解決軟體專案的大小事務、也能夠替...

閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

常見的程式碼壞味道（Code Smell or Bad Smell）圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別）如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別）一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團軟體開發之路［德國資深架構師給新手的建議］中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則，這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能或需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間或不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當...

閱讀完整內容

什麼是 gRPC ？

圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket，或精確地來說它是基於 HTTP/2 的協定，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了，根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 ....

閱讀完整內容

占空間的Google Chrome暫存檔

在一次使用CCleaner清除系統的垃圾的時候發現，怎麼Google Chrome怎麼有220M的網際網路快取資料？這時突然意會到，平時都只記得清除IE的Temporary Internet Files，卻忘了Google Chrome也是瀏覽器，一樣會產生暫存檔案，還有Google Earth產生的暫存檔居然更高達688M… Orz 因此突然間也非常好奇這些暫存的資料夾的路徑到底在哪裡呢？因為我們知道在Windows Vista/7 之後使用者資料已改在c:\Users 的下面，由於IE的是在"C:\Users\gelis\AppData\Local\Microsoft\Windows\Temporary Internet Files" 、所以我想應該也在這裡附近。果然讓我找到了！ Google Chrome : C:\Users\gelis\AppData\Local\Google\Chrome\User Data\Default\Cache Google Earth : C:\Users\gelis\AppData\Local\Google\GoogleEarth\models 可是突然間又發現Google Earth的資料夾居然是空的！這讓我很疑惑，明明掃出688M，究竟這些檔案是在哪裡呢？筆者的求知慾又非常強烈，每當發現問題如果不找出來是不罷休！因此常常熬夜只是為了找一個問題… 後來上Google才發現，原來我找錯位置，Google Earth的暫存資料是存在LocalLow的下面！不是Local的下面，所以路徑應該是如下： C:\Users\gelis\AppData\LocalLow\Google\GoogleEarth 而且是單一檔案"dbCache.dat"，總算解了疑惑 ^_^

閱讀完整內容

什麼是 gRPC（二）- 來撰寫第一個 Hello World 吧！

前言上一篇什麼是 gRPC ，筆者大致介紹了 gRPC Service 的基本概念，這一次，我們就來小試一下身手，撰寫一個 Hello World （迷之音：嘗試新技術時，總是得先來一個 Hello World ～我不想違背這良好傳統阿阿阿阿）使用環境 Visual Studio 2019 .NET Core 3.0.100-preview3-010431 開始進行撰寫 gRPC 除了先準備好基礎環境、選定一種作業系統／程式語言 Language 外、（Framework／SDK／Runtime）等環境備妥後，就可以開始撰寫， (1). 開始撰寫 gRPC 第一步就是先定義 .proto 協議了上一篇筆者提到，gRPC 的 Server 與 Client 必須使用相同的協議才可進行溝通，一般來說，你應該使用 protoc.exe 編譯器先行編譯過 greet.proto 協議檔，並產出 C# 程式碼檔案後才可繼續，而在 Visual Studio 2019 裡，拜 MSBuild 之賜，已經有人預先寫好 .Target 檔案了（什麼是 MSBuild ？什麼是附檔名 .Target 檔案可參考： MSBuild .targets 檔案）筆者先撰寫一個 SayHelloWorld 方法如下：在協議裡，除了在 service Class 撰寫要公開存取的方法外，必須在提供『傳入訊息型態』、『回傳訊息型態』，這邊我先定義兩個 message，一個是『 HelloMyFirstgRPC 』、另一個是『 HelloMyReply 』在撰寫 proto 協議檔時，建議先決定 message 回傳型態與傳入的型態，那麼 Visual Studio 2019 會有 InteillSense 的完整支援。不得不說 Visual Studio 2019 在 .proto 協議編輯上的支援已經算不錯了。注意：一般來說，Visual Studio 2019 會在背景裡自動編譯 .proto 協議檔案，但始有可能不會有任何提示，所以您也可以自行使用命令列工具進行手動編譯，如下圖，若編譯失敗會出現錯誤訊息，如下圖顯示 return 關鍵字錯誤： protoc.exe 編譯器 & 相關 MSBuild Tools 會隨著 NuGet 套件在 Vis...

閱讀完整內容

開啟Hyper-V的內部虛擬網路

撰文：吳俊毅時間：2010/7/14 在操作使用Hyper-V的Guest OS時，如果您是使用操作VMWare的方式來思考Hyper-V的虛擬網路設定的話您可能會碰壁，為什麼呢？在VMWare中只要Network的Getwary服務有啟動的話預設的設定就會自動將Guest OS的虛擬網卡透過實體網卡將Guest OS對應成一台網路實體IP位置，所以對實體網路而言好像就是多了台電腦。在Hyper-V中提供了3種虛擬網路類型： 1. 外部虛擬網路使虛擬機器直接對應外部實體網卡，這種方式會讓虛擬機器直接存取實體外部網路，筆者實際測試發現會直接搶住實體網路卡。 2. 內部虛擬網路所謂的內部虛擬網路是讓虛擬機器可以與外部機器溝通，簡單的說就是在您的本機中軟體虛擬一個如192.168.1.1~192.168.1.255的網段，通常用來測試一個虛擬網路環境，比如在當中架設Ap Server、Web Server，或甚至在虛擬網路中架設兩台DB Server來測試Cluster等等，不需使用實體網路來進行測試。 3. 私人虛擬網路只是讓虛擬機器彼此間通訊，與外部網路隔絕。如果您是VMWare的慣用者，第二種可能會比較適合您。筆者的測試環境是Windows Server 2008 Enterprise，使用的Hyper-V版本為6.0.6002.18005，要設定虛擬網路可從Hyper-V管理員的主畫面點選後會進入如下虛擬網路管理員的畫面：點選左邊的新增虛擬網路即可新增虛擬網路卡，讀者應該發現筆者已經新增了一張內部的網卡(筆者將其稱做Realtek RL8168 for External)。點選該內部網卡後，左半邊有可以設定的項目。筆者先說明想要幹什麼，筆者想讓Hyper-V內部網路同時具備內部虛擬網路的特性，同時又可以存取外部網路，同時外部實體機器也可以存取內部的虛擬機器，如同操作VMWare的習慣那樣。當新增了Realtek RL8168 for External內部網卡之後在實體電腦的網路連線也會新增一個Realtek RL8168 for External的區域連線，如下圖所示：接著將實體網卡與虛擬網卡均選起來，按右鍵選單的”新增到橋接器”，如下圖：這麼可以使剛才我們在Hyper-V內部的Realtek RL8168 for External內部網卡存...

閱讀完整內容

決戰 OOAD 系列（一）：使用 UML 分析的黃金三角

前言最近，經由前前公司的同事介紹下，他目前所處的單位有一個教育訓練的需求，該需求是這樣的：一、團隊中有許多人從 notes 轉換到.NET開發不久，目前工作為 SA ，但是對於從 SA 工作到 SD 的銜接總是有點卡卡的。二、團隊中現有 SD 對於 ASP.NET MVC 的開發不甚了解，希望藉由課程能夠順便讓其了解在 .NET 平台上能夠做到那些事情 (泛指在 Architecture Design 上，.NET 平台上能提供什麼？) 三、但是聽眾中大部分為 SA，所以希望能從系統分析開始講，一路到設計、實作，希望是一個一條龍的課程。四、加上目前團隊正在大量地使用 UML 作為系統分析的 notations，所以，希望系統分析 SA 的課程的部分已 UML 為主。恩，所以此課程名稱最便成為：『ASP.NET MVC 與（SA 系統分析／SD 系統設計）與 OOAD/UML 軟體系統開發課程』，課程名稱非常長吧？沒錯！XDDDD 而且內容非常非常非常硬….. 因為課程必須使用真實的例子，最好是客戶目前實際地 Case，而且要從 SA 開始 (教如何繪製 Use Case + Domain Class Diagram + Sequence Diagram)、到 SD 該如何讓 UML 與平台 & 語言有關？MDA 是怎麼回事等，所有繪製的 UML 圖型必須能夠與程式撰寫銜接上喔，因為許多人會畫圖，但是，你畫的圖能寫程式嗎？多數人是不清楚的，而剛好，我對於 UML 中的 SA 與 SD 如何銜接，剛好有些研究，而且最近五年來我手上的所有專案均是這麼做的！我所畫的圖型絕對可以直接產 Code，而且非常非常的清楚，對我而言，這樣的設計方式我已經行之有年，於是我很爽快地就答應了這一次的企業內訓課程，雖然這個課程真的非常硬，哈哈，我說非常硬的原因是，在這十天的課程過程中，到最後一天，我必須帶著學員真的撰寫出一個線上房屋貸款申請系統！要可以申請，對你沒聽錯，課程結束，要真的把一個系統做出來…. 這就是我說非常硬的原因。不過，還好，我做到了！哈哈對本文內容目前已錄製成線上課程：決戰 OOAD 系列課程、有興趣的讀者，可參考：課程連結進階使用案例分析技巧在上一篇文章中『從使用者需求，談架構設計』我提到了軟體專案的核心架構必須由使用者需求出發，因為...

閱讀完整內容

軟體架構設計：API 設計準則（二）、API Design-First 原則、策略與開發流程

軟體架構設計：API 設計準則（二）、API Design-First 原則、策略與開發流程圖片來源：https://coolshell.cn/articles/18024.html 前言本篇文章是上一篇『軟體架構設計：API 設計準則（一）、API 的設計開發與挑戰』的接續。前一篇文章中，我們探討了 API 的開發與挑戰，這還沒結束，這篇我們來聊聊什麼是 API Design-First 優先設計？這與傳統的軟體開發有些不同，這與我們已經熟悉的 RESTful API 的以 Resource-Based 為設計的設計概念也有些不同，下面，我們就來探討吧！為什麼需要 API 設計原則？在說明為什麼需要 API 設計原則時，我得先回到一開始的主題 API Design-First 優先設計，為什麼需要 API Design-First 呢？因為 API 設計有別於傳統軟體開發，差異等等下方解釋，在設計 API 時講求有效的產出，首先是別企業體的或企業組織為維持市場競爭力與獲利所擁有的能力與模型稱為：【商業能力】，而在開發 API 時將將用戶與開發者視為第一考量，講求的是盡可能讓用戶在不牽涉過多技術細節便可調用這個 API。在早期，許多企業未遵循 API Design-First 流程開發方法，而使用傳統方式設計 API，會後得到的結果可能就是『多次的砍掉重練及更冗長的開發週期』或最終 API 不為其他客戶所使用，甚至退出市場。從 RESTful 到 API Design-First 優先設計圖（一）、傳統 Resource-Based 的 RESTful API 原本我們熟知的 RESTful API 是將數位世界中的圖像、物件、後端的人員，都可稱為資源，這又稱作 Resource-Based API 的設計，因為 RESTful 將網路上的一切都視為資源。但是在API Design-First 的概念裡面： 1. 資源 ≠ 資料模型好的 API 設計提供的是該企業的數位能力，而不是後端的資料結構，因為 API 涉及的是跨企業之間的資料交換，這裡的 API 設計並不是傳統 SPA 應用程式裡面的 Front-end Framework 去呼叫的那個後端 API，這是兩個完全不同的開發情境，這必須先說明清楚。另...

閱讀完整內容

自訂 Astah Professional 的 Templates Scripting Language

disclaimer 圖片取自： https://jstermask.github.io/anycode/index.html 前言之前曾試用 Astah Community 就被其強大的功能所吸引，而且期繪製 UML 圖形的（方式／Style）比較符合 UML OMG 官方組織的規範，即便在我已經慣用 EA 的情況下，我仍然有時候，有些圖形我會使用 Astah 來畫。問題描述因為 Astah 是由 Java 所開發，即便 (UML／Professional) 版本支援【Export C#】的 MDA (Model Driven Architecture) 功能，但匯出的 C# 檔案總是與 C# 3.0 之後的語言版本格格不入，因為熟悉 C# 的開發人員都知道，C# 的 get and set accessor 到了 C# 3.0 時代已經加入了 Auto-Properties 的功能，也就是說，我可以將原先比較囉嗦的寫法：縮短改成如下，這叫做 Auto-Properties 但是，當我們使用 Astah Professional 所提供的 Export C# 功能時，如下 Class Diagram 中的 Account 在我們使用 Export C# 功能匯出 C# 程式碼時（如下視窗可讓我們自由選擇Class）但美中不足的是，即便你有勾選『Export properties as C# 3.0 automatic properties』但是透過 Astah Professional 所產生的 C# Class 檔案中每一個 Properties 卻還是如下：由此可見，Astah 對於 C# 的支援並不是那麼友善，又或者說，Astah 所支援的 C# 根本還停留在 C# 1.0 的年代，而且不光是 Astah 有這個問題，還有許多 UML Case Tool 對於 C# 語言的支援都不是那麼友善，包括 EA 也是，這我就不一一點名了。對 C# 支援最完整的還是 Visual Studio 提供的塑模化 Modeling 的功能了，可惜的是官方到了 Visual Studio 2017 時就拿掉了 Modeling 的功能，理由是塑模化的功能很少人用，但這不能當作理由吧？XDDD 因為企業內部真...

閱讀完整內容

客戶端出現找不到來自來源 DCOM 之事件識別碼 10016 的描述的解法

最近客戶端Server事件檢視器常常出現一個訊息：找不到來自來源 DCOM 之事件識別碼 10016 的描述。本機電腦可能並未安裝引發此事件的元件，或安裝已損毀。您可以在本機電腦上安裝或修復該元件。如果事件源自其他電腦，則儲存它們時必須一併儲存顯示資訊。下列資訊已隨附於該事件: 應用程式特定本機啟用 {0C0A3666-30C9-11D0-8F20-00805F2CD064} NT AUTHORITY NETWORK SERVICE S-1-5-20 通常面對如{0C0A3666-30C9-11D0-8F20-00805F2CD064} 這樣的ClassID可以調查Registry的HKEY_CLASSES_ROOT\CLSID機碼，如圖(一)。圖(一)、找到的{0C0A3666-30C9-11D0-8F20-00805F2CD064}的ClassID機碼發現此機碼就是Microsoft的指令碼偵錯管理員MDM.EXE (Machine Debug Manager)所註冊的機碼。因為ASP.NET所執行的Network Service並沒有權限進行偵錯而導致此訊息的發生。如圖(二) 圖(二)、為Microsoft的指令碼偵錯管理員MDM.EXE (Machine Debug Manager) 解決方式可以透過Dr. Watson來改變系統預設的偵錯管理員，可在開始工具列執行： drwtsn32 –i 引數-i表示Install的意思，這會將Dr. Watson安裝為系統預設的錯誤處理器此問題即可解決！註：此問題解法只適用於Windows XP/2003，在Vista/7/2008機制以不同，也找不到機碼{0C0A3666-30C9-11D0-8F20-00805F2CD064}，當然也找不到drwtsn32.exe

閱讀完整內容