乱七八糟

大牛也犯错误啊

Coder Jozu — Fri, 20 May 2005 01:57:00 GMT

近来在调试一个跟踪系统内存的驱动，可以参考的书是少之又少，当然Mark Russinovich写的Inside Windows 2000和Inside windows XP/2003是不可或缺的资料，可是在跟踪一个关键问题的时候，发现原来Mark Russinovich也犯下了一个重要错误！他在书上说从windowsXP开始，各个进程的Working set是由一个新的同步对象EX_PUSH_LOCK来同步存取的，我按照他的指示，做了锁定和解锁，发现----居然不工作！！！努力研究了好几天，终于发现，XP到XP1根本就没有采用EX_PUSH_LOCK，还是用的早先的FAST_MUTEX来保持同步。。。。。。害我跟踪了将近三天啊。

写下来自勉，不能随便相信别人，哪怕他是世界公认的牛人。

七猫，给你个参考，评论上放不下，就当随笔吧

Coder Jozu — Wed, 23 Mar 2005 07:08:00 GMT

Bugchecks Explained: PFN_LIST_CORRUPT
OSR Staff | Published: 24-Aug-04| Modified: 24-Aug-04
What Happened?
Windows tracks physical pages of memory using a table called the Page Frame Database. This database (which actually is just a big one-dimensional array) is indexed by physical page number. As a result, the page frame database is typically referred to as the Page Frame Number list or PFN.

Every page of physical memory has an associated PFN entry. Each PFN entry contains information about the state of its corresponding physical page in the system. This state includes information about whether the corresponding physical page is in use, how it’s being used, a count of active users of the page, and a count of pending I/O operations on the page.

Depending on the pages state, a PFN entry may be on one of several lists that the Memory Manager maintains. The listheads for these lists are simple global variables that are used for quick access to PFN entries of certain types. For example, one such list would be the list that contains all the modified pages that need to be written to disk.

Because all the PFN lists and entries are present in the high half of kernel virtual address space, they are subject to corruption through stray pointer accesses (such as by errant drivers or other similar kernel-mode modules). Also, the count in the PFN that tracks the number of I/O related accesses to a given physical page can be corrupted by improper MDL handling.

Whenever Windows detects that any of the PFN lists or any of the PFN entries themselves have become invalid, the system halts with a PFN_LIST_CORRUPT bugcheck.

Who Did It?
This bugcheck usually occurs for one of two reasons, the first reason being memory corruption. If there is a buggy driver in the system that is writing on memory that it does not own, it could easily corrupt one of the PFN lists or entries. In order to rule this out, you should run Driver Verifier with Special Pool enabled for suspect drivers in the system. This will hopefully allow you to catch the misbehaving driver in the act of scribbling memory, instead of receiving a crash sometime later when the O/S discovers the damage.

The second cause for this bugcheck is incorrect MDL handling. For example, one use of MDLs is to allow you to "lock" the physical memory that backs a virtual address range so that the memory stays resident while your driver is accessing it. This is achieved by using the MmProbeAndLockPages DDI. One of the things that this DDI does is take out a reference on the PFN entries of the underlying physical pages, ensuring that the Memory Manager does not page them out. The corresponding DDI to undo this operation, MmUnlockPages, is responsible for decrementing the reference counts taken out in the previous call. If a driver happens to call MmUnlockPages too many times on an MDL, the reference count on the underlying PFN entries could drop to below zero (to 0xFFFFFFFF). The system considers this to be a critical error, as one or more of the PFN entries is obviously invalid. Therefore, this bugcheck will occur.

If your driver or a driver in your stack is being blamed for a PFN_LIST_CORRUPT bugcheck, go over your code and make sure that you are properly handling your MDLs . Remember that even if you do not create or destroy any MDLs directly, you play a part in the creation and destruction of them if you handle IRPs whose buffers are described with DIRECT_IO. Driver Verifier and the checked build of Windows can help pinpoint IRP and MDL handling errors.

How Should I Fix It?
How this is fixed varies depending on the reason of the bugcheck. Using Driver Verifier and the checked build of the O/S should allow you to pinpoint the driver that is either corrupting memory or mishandling MDLs. If the offending driver is not a driver that you have any control over, the only available option is disabling the driver until a fixed version is available.

Related WinDBG Commands
· !memusage
· !pfn
Related O/S Structures
· nt!_MMPFN
· nt!_MMPFNENTRY
· nt!_MMPFNLIST
Related O/S Variables
· nt!MmBadPageListHead
· nt!MmStandbyPageListHead
· nt!MmModifiedNoWritePageListHead
· nt!MmModifiedPageListHead
· nt!MmFreePageListHead
· nt!MmZeroedPageListHead
· nt!MmRomPageListHead

简单的debugview

Coder Jozu — Wed, 23 Mar 2005 02:55:00 GMT

sysinternals的dbgview想必大家都用过，我写了一个简单的，只监视user层OutputDebugString的输出，原理都包含在代码里了，希望对你有帮助，没有的话就算了：P
// DBMntor.cpp : Little dbgview。。。。
// Coder Jozu
//
#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include <stdlib.h>

#define PAGE_SIZE 4096

#define DBWIN_MAP   "DBWIN_BUFFER"
#define DBWIN_WRITEVENT  "DBWIN_BUFFER_READY"
#define DBWIN_READEVENT  "DBWIN_DATA_READY"

typedef struct _tag_DBMap
{
DWORD dwProcessId;
CHAR szString[PAGE_SIZE - sizeof(DWORD)];
} DB_MAP, *PDB_MAP;

int main(int argc, char* argv[])
{
HANDLE hMap;
PDB_MAP pDBMap;

HANDLE hEventRead;
HANDLE hEventWrite;
HANDLE hMutex;

hMutex = CreateMutex(NULL, FALSE, "DBWinMutex");

hEventRead = CreateEvent(NULL, TRUE, FALSE, DBWIN_READEVENT);
hEventWrite = CreateEvent(NULL, TRUE, FALSE, DBWIN_WRITEVENT);
if(!hEventRead || !hEventWrite)
{
return 0;
}

hMap = CreateFileMapping(INVALID_HANDLE_VALUE,
        NULL,
        PAGE_READONLY,
        0,
        PAGE_SIZE,
        DBWIN_MAP);
if(!hMap)
  return 0;

pDBMap = (PDB_MAP)MapViewOfFile(hMap,
        FILE_MAP_READ,
        0,
        0,
        0);
if(!pDBMap)
{
  CloseHandle(hMap);
  return 0;
}

SetEvent(hEventWrite);
while(TRUE)
{

  WaitForSingleObject(hEventRead, INFINITE);

  printf("%d==>%s\n", pDBMap->dwProcessId, pDBMap->szString);

}

return 0;
}

NB代码，赶紧记下来

Coder Jozu — Thu, 10 Mar 2005 08:49:00 GMT

定位自己：
__asm {
    fldz
    fnstenv byte ptr [esp-0ch]
    pop ebx
}

防止出现0x00的相对偏移跳转：
    push 0FFFFFFEBh
JMPOUT    $-4
    db    NEXT - JMPOUT - 1
    call JMPOUT
    jmp end
NEXT:
    .......
end:

计算位数小算法

Coder Jozu — Wed, 09 Mar 2005 03:27:00 GMT

// Bits.cpp : Calculate numbers of bits on a long number.
// Coder Jozu

#include "stdafx.h"

int main(int argc, char* argv[])
{
long x;
int num;
char buff[128];

while(1)
{
  printf("enter a hex value:");
  gets(buff);
  if(buff[0] == 'q' || buff[0] == 'Q')
   break;

  if(!sscanf(buff, "%X", &x))
  {
   printf("Invalid number.\n");
   continue;
  }

  __asm
  {
   push esi
   push eax

   mov eax, x
   mov ecx, 32
   xor esi, esi
next:
   shr eax, 1
   jc AddOne
   dec ecx
   jcxz end
   jmp next
AddOne:
   inc esi
   jmp next
end:
   mov num, esi
   pop eax
   pop esi
  }

  printf("number of %X has %d bits.\n", x, num);
}
return 0;
}

装载一个exe，并且执行

Coder Jozu — Sat, 29 Jan 2005 19:20:00 GMT

发现一个好API，奇怪的是M$怎么就是不公开呢

Coder Jozu — Wed, 26 Jan 2005 15:11:00 GMT

备忘一下

Coder Jozu — Wed, 19 Jan 2005 21:45:00 GMT

Super administrator

Coder Jozu — Mon, 17 Jan 2005 06:05:00 GMT

监视一个指定进程是不是启动

Coder Jozu — Tue, 14 Dec 2004 18:03:00 GMT