• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Ay's Blog@CNSSUESTC

            誰動了我的指針?--記一次windbg內存斷點的使用

             

            寫驅動的時候有個地方老是藍屏,看了dump發現數據被非法篡改了.

            數據初始化如下

             

            if(record_set_ptr != NULL )
            {
                record_set_ptr->look_aside_pool_ptr = g_user_control_context.look_aside_pools[type] ;
                record_set_ptr->type = type ;
                record_set_ptr->buffer_size = notify_count * unit_size_of ;
                record_set_ptr->units_count = notify_count ;
                record_set_ptr->complete_count = 0 ;
            }

            然后在調用ExFreeToNPagedLookasideList傳入record_set_ptr->look_aside_pool_ptr 的時候掛了,發現record_set_ptr->look_aside_pool_ptr已經被改了.

             

            為了跟蹤數據在哪里被修改了,先在數據初始化的地方下斷,然后記下record_set_ptr->look_aside_pool_ptr 的地址:0x85c16018

            對這個內存下個斷點

            1: kd> ba w4 85c16018

            w表示在寫入時斷下,4表示監控范圍,單位是字節 

            整個命令的意思就是讓調試器在系統寫入內存85c16018-85c1601b這個地址范圍的時候中斷

            OK,命令下完,F5一下就立馬斷下來了

            1: kd> g
            Breakpoint 3 hit
            nt!memcpy+0x33:
            8053b583 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]


            此時edi的值: 0x85c16018

             

            最后看一下函數堆棧,發現是字符串拷貝越界覆蓋了后面的數據.... 

            后面又想到,出錯時record_set_ptr->look_aside_pool_ptr 的值是0x005c0065

            這么明顯的字符串特征竟然沒意識到....一看出錯值就應該知道是字符串覆蓋造成的.....

            posted on 2012-01-03 15:07 __ay 閱讀(3851) 評論(3)  編輯 收藏 引用 所屬分類: Debugging

            Feedback

            # re: 誰動了我的指針?--記一次windbg內存斷點的使用 2012-01-05 09:33 zuhd

            和樓主分享一下:
            一般遇到這種需要下內存斷點的調試,我可能會先檢查代碼,應該會有90%的概率是越界造成的,確定該內存是在堆還是棧,然后排查該變量上下的兩個變量,基本都能找到,呵呵。請問樓主是UESTC的嗎?  回復  更多評論   

            # re: 誰動了我的指針?--記一次windbg內存斷點的使用 2012-01-05 13:30 __ay

            呵呵 你也是UESTC的?不過我已經畢業了
            當然如果越界的時候能直接引發崩潰,那么看代碼直接就能解決問題
            但是在越界讀寫不引發crash,直到引用被覆蓋的數據的時候才崩潰,如果這個時候代碼中很難定位到被覆蓋數據是什么時候寫的,那應該用內存斷點會比較好了@zuhd
              回復  更多評論   

            # re: 誰動了我的指針?--記一次windbg內存斷點的使用 2012-01-05 14:24 dourgulf

            好經驗分享,不錯  回復  更多評論   


            婷婷伊人久久大香线蕉AV| 欧美一区二区精品久久| 久久久精品人妻无码专区不卡| 人人狠狠综合久久亚洲婷婷 | 91精品国产综合久久久久久| 久久久精品2019免费观看| 中文字幕亚洲综合久久2| 久久久久国产精品三级网| 狠狠精品久久久无码中文字幕| 久久精品国产亚洲av麻豆色欲| 久久91精品综合国产首页| 精品国产乱码久久久久久呢| 久久国产精品99精品国产987| 久久久久久国产精品美女| A狠狠久久蜜臀婷色中文网| 久久久久久久久久久精品尤物 | 亚洲国产精品综合久久网络| 午夜天堂av天堂久久久| 久久久久国产成人精品亚洲午夜| 99久久做夜夜爱天天做精品| 亚洲国产精品久久久久婷婷软件| 久久精品免费一区二区| 国产精品成人99久久久久 | 久久久噜噜噜久久熟女AA片 | 国产免费久久精品丫丫| 久久精品亚洲一区二区三区浴池| 久久亚洲中文字幕精品一区四| 久久久久亚洲精品无码蜜桃| 久久天天躁狠狠躁夜夜avapp | 久久久久久国产精品无码下载| 久久精品夜夜夜夜夜久久| yy6080久久| 亚洲va久久久久| 亚洲日韩欧美一区久久久久我| 精品久久久久久久久久久久久久久| 久久久精品2019免费观看| 色8久久人人97超碰香蕉987| 日韩乱码人妻无码中文字幕久久| 无码人妻久久一区二区三区蜜桃| 久久久久国产一级毛片高清板| 国产国产成人久久精品 |