如何分析文件

㈠ 拿到招標文件後怎麼分析，主要分析哪些內容

招標文件內容一般包括如招標公告（或投標邀請書)、投標人須知、評標辦法、合同條款及格式、圖紙、工程量清單、技術標准和要求、投標文件格式等內容，需要重點關注每一項的要求和重點事項,具體分析重點如下：

1、看資格審查

資格審查是招標項目的必要程序，所以投標人必須要關注。看資格審查，主要是看業績、規模、財務、人員等等的硬性指標，再看看自己的企業投標有沒有硬性門檻。雖然本著鼓勵競爭的原則，資格審查一般不會要求太高或者太特殊，但是也要認真對待。

2、看評標方法

主要看招標文件中的一些商務、技術的評分標准。根據自己公司的實力進行分析，要求什麼標准，客觀分和主觀分，根據這些制定投標策略，尋找自己的優勢，彌補自己的劣勢，做到心中有譜。

3、看投標人須知前附表

細看投標人須知前附表，這裡面涵蓋的都是關鍵性條款，認真研讀有助於理清楚整個投標文件要怎麼做，尤其是包含一些不可偏離條款(實質性條款)。

4、看合同部分和技術規范書

結合商務不可偏離條款，看合同大致要求，結算方式，付款條件等等。這部分要和技術人員詳細充分交流，盡量或者完全滿足招標人的要求。

5、字紙標書的製作

有需要製作字紙標書文件的，一定要製作相同數量的字紙標書文件簽名蓋章，按要求進行密封。招標文件要求簽字蓋章的地方一定不要忘記。

6、記住關鍵點

關鍵點一般包括：公示期，投標截止日期，保函或者保證金，投標開標地點，文件格式等。

一份招標文件內容較多，除了人工去看外，也可以藉助如標/事/通·招標文件解析工具來提升工作效率。招標文件解析可以實現對招標文件全面解析，會提示招標文件關鍵信息，進行結構化節點處理，建立快速導航，實現便捷閱讀；同時在文件中明確標注出招標星號項、廢標項信息，保障投標人的投標合規不漏項。

擴充資料：

招標文件是招標工程建設的大綱，是建設單位實施工程建設的工作依據，是向投標單位提供參加投標所需要的一切情況。因此，招標文件的編制質量和深度，關系著整個招標工作的成敗。招標文件的繁簡程度，要視招標工程項目的性質和規模而定。建設項目復雜、規模龐大的，招標文件要力求精練、准確、清楚;建設項目簡單、規模小的，文件可以從簡，但要把主要問題交代清楚。招標文件內容，應根據招標方式和范圍的不同而異。工程項目全過程總招標，同勘察設計、設備材料供應和施工分別招標，其特點性質都是截然不同的，應從實際需要出發，分別提出不同內容要求。

招標文件主要內容：

1.招標公告（或投標邀請書)

2.投標人須知

3.評標辦法

4.合同條款及格式

5.圖紙、工程量清單

6.技術標准和要求

7.投標文件格式

㈡ dsYM文件分析方法

1、要使用Xcode符號化 crash log，你需要下面所列的3個文件：
①crash報告（.crash文件）
②符號文件 (.dsymb文件)
③應用程序文件 (.app文件）
2、把這3個文件放到同一個目錄下，打開Xcode的Window菜單下的organizer，然後點擊Devices tab，然後選中左邊的Device Logs。
然後把.crash文件拖到Device Logs或者選擇下面的import導入.crash文件。
這樣你就可以看到crash的詳細log了。

1、將「.app「, 「.dSYM」和 ".crash"文件放到同一個目錄 ./Crash 下。
2、在Xcode中找到 symbolicatecrash 工具

找到後將 symbolicatecrash 拷貝到 ./Crash 目錄下
3、切換到 ./Crash 目錄下。 打開終端(Terminal)然後輸入如下的命令：
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
然後輸入命令：
./symbolicatecrash appName.crash appName.app > appName.log
現在，符號化的crash log就保存在appName.log中了。

我們使用atos命令來完成符號化，具體命令如下： $ atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate> 其中:

具體示例： atos -arch arm64 -o CrashDemo.app.dSYM/Contents/Resources/DWARF/CrashDemo -l 0x0000000102838010 0x0000000102838119

查看dsYM文件UUID：
方法一： 通過命令行查看dSYM文件的UUID
① xcrun dwarfmp --uuid <dSYM文件>
② dwarfmp --uuid TestAvoidCrash.app.dSYM/
③ dwarfmp --uuid TestAvoidCrash.app/TestAvoidCrash

方法二：通過符號表文件查看UUID
符號表文件的UUID與dSYM文件的UUID是一致的，因此可以通過符號表工具生成的符號表文件來查看dSYM文件的UUID：
生成符號表文件(.zip) ---> 解壓符號表文件(.symbol) ---> 使用文本編輯器打開符號表文件

㈢ linux core 文件 怎麼分析

Core，又稱之為Core Dump文件，是/Linux操作系統的一種機制，對於線上服務而言，Core令人聞之色變，因為出Core的過程意味著服務暫時不能正常響應，需要恢復，並且隨著吐Core進程的內存空間越大，此過程可能持續很長一段時間（例如當進程佔用60G+以上內存時，完整Core文件需要15分鍾才能完全寫到磁碟上），這期間產生的流量損失，不可估量。
凡事皆有兩面性，OS在出Core的同時，雖然會終止掉當前進程，但是也會保留下第一手的現場數據，OS彷彿是一架被按下快門的相機，而照片就是產出的Core文件。裡面含有當進程被終止時內存、CPU寄存器等信息，可以供後續開發人員進行調試。

關於Core產生的原因很多，比如過去一些Unix的版本不支持現代Linux上這種GDB直接附著到進程上進行調試的機制，需要先向進程發送終止信號，然後用工具閱讀core文件。在Linux上，我們就可以使用kill向一個指定的進程發送信號或者使用gcore命令來使其主動出Core並退出。如果從淺層次的原因上來講，出Core意味著當前進程存在BUG，需要程序員修復。從深層次的原因上講，是當前進程觸犯了某些OS層級的保護機制，逼迫OS向當前進程發送諸如SIGSEGV(即signal 11)之類的信號, 例如訪問空指針或數組越界出Core，實際上是觸犯了OS的內存管理，訪問了非當前進程的內存空間，OS需要通過出Core來進行警示，這就好像一個人身體內存在病毒，免疫系統就會通過發熱來警示，並導致人體發燒是一個道理（有意思的是，並不是每次數組越界都會出Core，這和OS的內存管理中虛擬頁面分配大小和邊界有關，即使不出Core，也很有可能讀到臟數據，引起後續程序行為紊亂，這是一種很難追查的BUG）。
說了這些，似乎感覺Core很強勢，讓人感覺缺乏控制力，其實不然。控制Core產生的行為和方式，有兩個途徑：
1.修改/proc/sys/kernel/core_pattern文件，此文件用於控制Core文件產生的文件名，默認情況下，此文件內容只有一行內容：「core」，此文件支持定製，一般使用%配合不同的字元，這里羅列幾種：
%p 出Core進程的PID
%u 出Core進程的UID
%s 造成Core的signal號
%t 出Core的時間，從1970-01-0100:00:00開始的秒數
%e 出Core進程對應的可執行文件名

2.Ulimit –C命令，此命令可以顯示當前OS對於Core文件大小的限制，如果為0，則表示不允許產生Core文件。如果想進行修改，可以使用：
Ulimit –cn
其中n為數字，表示允許Core文件體積的最大值，單位為Kb，如果想設為無限大，可以執行：
Ulimit -cunlimited
產生了Core文件之後，就是如何查看Core文件，並確定問題所在，進行修復。為此，我們不妨先來看看Core文件的格式，多了解一些Core文件。

㈣ 如何用WinDbg分析MEMORY.DMP文件

在C++實際開發過程中，開發出來的程序，一般情況下由開發人員進行單元測試，然後移交給測試人員進行測試。在開發人員測試出現的bug，我們可以直接在本地進行調試。如果測試人員測試出崩潰級別的bug，如果我們需要調試往往藉助於vs提供的Remote Debugger工具進行遠程調試，然是當程序在用戶手中出現崩潰此時我們可以採用Remote Debugger進行調試，但是如果此時開發人員無法直接去用戶現場調試，此時就需要用戶生成DMP文件，以便開發人員使用DMP文件進行分析。

本文主要介紹C++開發過程中出現程序崩潰後，如何進行分析定位bug（基於xp系統）。

一、DMP文件獲取設置
（1）在運行窗口中輸入 drwtsn32 -i ，並且點擊確定
WinDbg分析DMP文件方法完全攻略

（2）在（1）確定後彈出如下對話框
WinDbg分析DMP文件方法完全攻略

（3）在（2）彈出的確定框後點擊確定按鈕完成，將Dr.Watson設置為默認應用程序調試程序。
Dr.Watson系統自帶的程序。

（4）再次在運行窗口中輸入：drwtsn32，如下圖：
WinDbg分析DMP文件方法完全攻略

（5）點擊確定按鈕，在彈出的對話框中按照下列方式設置
WinDbg分析DMP文件方法完全攻略

(6) 點擊確定按鈕完成DMP文件設置。

二、關閉Dr.Watson方法
（1）打開注冊表
（2）在注冊表中進入主鍵［HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AeDebug］，然後將「AUTO」鍵值設置為0如下圖：
WinDbg分析DMP文件方法完全攻略

三、Windbg下載，下載完成後安裝

四、DMP文件獲取
(1) 用vs2010創建一個基於win32的程序，其源碼如下：
WinDbg分析DMP文件方法完全攻略

(2)我們知道在學習C++中整數不能跟0進行除運算，否則會引起程序崩潰。而（1）中就是編寫能觸發0的異常，導致程序結束運行的程序。編譯（1）中的程序，結果如下：
WinDbg分析DMP文件方法完全攻略

（3）運行（2）中test.exe程序 ，程序崩潰。如下圖：
WinDbg分析DMP文件方法完全攻略

(4) 按照《一、DMP文件獲取設置》步驟實現Dr.Watson設置為默認應用程序調試程序。

(5)再次運行運行（2）中test.exe程序 如下圖：
WinDbg分析DMP文件方法完全攻略

點擊確定完成dmp文件的生成。

（6）打開在（4）中設置dmp文件路徑。（本例中默認地址為：C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson）如下圖：
WinDbg分析DMP文件方法完全攻略

其中user.dmp就是我們需要的dmp文件。

五、分析《四、DMP文件獲取》中獲取的DMP文件。

㈤ dmp文件是什麼，如何分析dmp文件

dmp文件是系統錯誤的內存轉儲文件。當電腦藍屏或系統崩潰時，Windows會將錯誤報告存儲在一個後綴名為「.DMP」的文件里。該文件記錄了系統錯誤的詳細信息，技術人員可以分析它找到系統崩潰的原因，從而解決問題。分析dmp文件的步驟如下：

1、首先我們要找到mp文件，mp文件則是記錄了藍屏之前數據在內存中的情況。