Jesteś tutaj

Windows

Enumerating GDI Objects

published by Kuling on wt., 2011-01-25 09:09

Cytat:

GDIView is a unique tool that displays the list of GDI handles (brushes, pens, fonts, bitmaps, and others) opened by every process. It displays the total count for each type of GDI handle, as well as detailed information about each handle.
This tool can be useful for developers that need to trace GDI resources leak in their software.

http://www.nirsoft.net/utils/gdi_handles.html

For Windows 95

Cytat:

Resource Leaks: Detecting, Locating, and Repairing Your Leaky GDI Code

http://msdn.microsoft.com/en-us/magazine/cc301756.aspx

For Windows >XP

Cytat:

In a previous article, the author devised a simple method to detect Graphical Device Interface (GDI) objects that are not properly released by Win32-based applications on Windows 9x platforms. Because some newer versions of Windows require a slightly different approach to GDI leaks, the author has updated his techniques for those operating systems. He builds and explains two tools designed to detect and eradicate GDI leaks in applications running on Windows XP, Windows 2000, and Windows NT.

http://msdn.microsoft.com/en-us/magazine/cc188782.aspx

Pushing the Limits of Windows: USER and GDI Objects
http://blogs.technet.com/b/markrussinovich/archive/2010/02/24/3315174.aspx
http://blogs.technet.com/b/markrussinovich/archive/2010/03/31/3322423.aspx

Kategorie:

C++

Programowanie

Windows

Czytaj dalej wpis Enumerating GDI Objects
Blog
186 odsłon

Tracking heap leaks - gflags and WinDbg - Create user mode stack trace database

published by Kuling on ndz., 2010-11-14 13:39

This is example how to trace memory leaks using gflags and WinDbg.
I've some application called heaps1.exe which generates 1000000 (0xF4240) memory leaks elements of size 666 Bytes (0x29A).

1. Enable generating user mode stack trace database. You can also make it from GUI.
C:Program FilesDebugging Tools for Windows (x86)>gflags.exe /i heaps1.exe +ust

2. Run application and generate leaks.

3. Attach WinDbg to your process (heaps1.exe).

4. Load necessary symbols pdb.

5. Break into debugger if necessary.

6. And now magic words:

6a. At first check which heaps is leaking the most.

0:001> !heap -s
NtGlobalFlag enables following debugging aids for new heaps:
    validate parameters
    stack back traces
Heap     Flags   Reserv Commit Virt   Free List   UCR Virt Lock Fast
                    (k)     (k)    (k)     (k) length      blocks cont. heap
-----------------------------------------------------------------------------
00150000 58000062    1024     76     76     34     2     1    0      0   L
00250000 58001062      64     24     24     11     1     1    0      0   L
00260000 58008060      64     12     12     10     1     1    0      0
00390000 58001062 883776 679796 679796      6     1     1    0      0   L
003d0000 58001062      64     16     16      0     0     1    0      0   L
-----------------------------------------------------------------------------

OK. We see that heap 00390000 has outstanding amoutn of allocations.

6b. Let make statistics of this heap.

0:001> !heap -stat -h 00390000
heap @ 00390000
group-by: TOTSIZE max-display: 20
    size     #blocks     total     ( %) (percent of total busy bytes)
    29a f4240 - 27b25a80 (99.99)
    2012 2 - 4024 (0.00)
    1504 1 - 1504 (0.00)
    800 2 - 1000 (0.00)
    204 3 - 60c (0.00)
    214 2 - 428 (0.00)
    400 1 - 400 (0.00)
    5c 7 - 284 (0.00)
    16 19 - 226 (0.00)
    220 1 - 220 (0.00)
    1fc 1 - 1fc (0.00)
    7c 4 - 1f0 (0.00)
    1c e - 188 (0.00)
    34 6 - 138 (0.00)
    98 2 - 130 (0.00)
    28 7 - 118 (0.00)
    88 2 - 110 (0.00)
    80 2 - 100 (0.00)
    fe 1 - fe (0.00)
    2a 6 - fc (0.00)
OK. Now we see that almost all allocations have size 0x29a (666 Bytes) and there is 0xf4240 allocations of this size.

6c. Let check who allocated these bytes. There will come gigantic flood. You can break it by pressing <ctrl>+<break>

!heap -flt s 29a

0:001> !heap -flt s 29a
    _HEAP @ 150000
    _HEAP @ 250000
    _HEAP @ 260000
    _HEAP @ 390000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0039c9f8 0057 0000 [07]   0039ca00    0029a - (busy)
        0039ccb0 0057 0057 [07]   0039ccb8    0029a - (busy)
        0039cf68 0057 0057 [07]   0039cf70    0029a - (busy)
        0039d220 0057 0057 [07]   0039d228    0029a - (busy)
        0039d4d8 0057 0057 [07]   0039d4e0    0029a - (busy)
        0039d790 0057 0057 [07]   0039d798    0029a - (busy)
        0039da48 0057 0057 [07]   0039da50    0029a - (busy)
        0039dd00 0057 0057 [07]   0039dd08    0029a - (busy)
        0039dfb8 0057 0057 [07]   0039dfc0    0029a - (busy)
        0039e270 0057 0057 [07]   0039e278    0029a - (busy)
        0039e528 0057 0057 [07]   0039e530    0029a - (busy)
        0039e7e0 0057 0057 [07]   0039e7e8    0029a - (busy)
       [....]
        3190b518 0057 0057 [07]   3190b520    0029a - (busy)
        3190b7d0 0057 0057 [07]   3190b7d8    0029a - (busy)
        3190ba88 0057 0057 [07]   3190ba90    0029a - (busy)
        3190bd40 0058 0057 [07]   3190bd48    0029a - (busy)
        3190c000 0057 0058 [07]   3190c008    0029a - (busy)
        3190c2b8 0057 0057 [07]   3190c2c0    0029a - (busy)
    _HEAP @ 3d0000

6d. And now see callstack of some random allocation.

0:001> !heap -p -a 0039d220
    address 0039d220 found in
    _HEAP @ 390000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0039d220 0057 0000 [07]   0039d228    0029a - (busy)
        Trace: 030b
        7c96eed2 ntdll!RtlDebugAllocateHeap+0x000000e1
        7c94b394 ntdll!RtlAllocateHeapSlowly+0x00000044
        7c918f21 ntdll!RtlAllocateHeap+0x00000e64
        78583db8 MSVCR90!malloc+0x00000079
        78a34b52 mfc90u!operator new+0x00000033
        401450 Heaps1!CHeaps1Dlg::OnBnClickedButton1+0x00000010
        78a6d3e9 mfc90u!CCmdTarget::OnCmdMsg+0x00000124
        78a5de60 mfc90u!CPropertySheet::OnCmdMsg+0x0000001d
        78a3ff73 mfc90u!CWnd::OnCommand+0x00000092
        78a3f75b mfc90u!CWnd::OnWndMsg+0x00000066
        78a3f6ce mfc90u!CWnd::WindowProc+0x00000024
        78a3e2f4 mfc90u!AfxCallWndProc+0x000000a3
        78a3e580 mfc90u!AfxWndProc+0x00000037
        78a3c247 mfc90u!AfxWndProcBase+0x00000056
        7e418734 USER32!InternalCallWinProc+0x00000028
        7e418816 USER32!UserCallWinProcCheckWow+0x00000150
        7e428ea0 USER32!DispatchClientMessage+0x000000a3
        7e428eec USER32!__fnDWORD+0x00000024
        7c90e473 ntdll!KiUserCallbackDispatcher+0x00000013
        7e4292e3 USER32!SendMessageW+0x0000007f
        773f735f COMCTL32!Button_NotifyParent+0x0000003d
        773f7441 COMCTL32!Button_ReleaseCapture+0x000000d7
        773f9746 COMCTL32!Button_WndProc+0x00000887
        7e418734 USER32!InternalCallWinProc+0x00000028
        7e418816 USER32!UserCallWinProcCheckWow+0x00000150
        7e4189cd USER32!DispatchMessageWorker+0x00000306
        7e418a10 USER32!DispatchMessageW+0x0000000f
        7e4274ff USER32!IsDialogMessageW+0x00000572
        78a6c38d mfc90u!CWnd::IsDialogMessageW+0x00000032
        78a42739 mfc90u!CWnd::PreTranslateInput+0x0000002d
        78a5b244 mfc90u!CDialog::PreTranslateMessage+0x00000095
        78a40974 mfc90u!CWnd::WalkPreTranslateTree+0x00000023
6e. Let see how CHeaps1Dlg::OnBnClickedButton1 looks.

void CauseLeak()
{
    int nCount = 1000000;
    for (int i = 0; i < nCount; ++i)
    {
        new char[666];
    }
}

void CHeaps1Dlg::OnBnClickedButton1()
{
CauseLeak();
}

7. It is enough to fix bad code.

Kategorie:

C++

Programowanie

Windows

Heap fragmentation and Low-fragmentation Heap

published by Kuling on sob., 2010-11-13 19:07

1. Heap fragmentation

Fragmenting a heap is something I haven’t worried about for years. When you allocate and deallocate memory in certain patterns you can leave areas of unallocated memory stranded inamongst allocated memory. This can lead to the situation where you have, say, 10Mb of memory free, but yet an allocation for 256 bytes fails as although you have all this free memory, none if it is in a big enough continuous lump to give you your 256 bytes.

http://xania.org/200512/crt-heap-fragmentation-in-windows

2. Low-fragmentation heap definition

The LFH is not a separate heap. Instead, it is a policy that applications can enable for their heaps. When the LFH is enabled, the system allocates memory in certain predetermined sizes. When an application requests a memory allocation from a heap that has the LFH enabled, the system allocates the smallest block of memory that is large enough to contain the requested size. The system does not use the LFH for allocations larger than 16 KB, whether or not the LFH is enabled.

Applications that benefit most from the LFH are multi-threaded applications that allocate memory frequently and use a variety of allocation sizes under 16 KB. However, not all applications benefit from the LFH. To assess the effects of enabling the LFH in your application, use performance profiling data.

http://msdn.microsoft.com/en-us/library/aa366750%28VS.85%29.aspx

3. What is the cause of fragmentation

Imagine, for concreteness, a program that allocates memory in a loop like this:

* p1 = alloc(128)
* p2 = alloc(128)
* free(p1)
* p3 = alloc(96)
* (Keep p2 and p3 allocated.)
* Repeat

Under the classical model, when the request for 96 bytes comes in, the memory manager sees that 128-byte block (formerly known as p1) and splits it into two parts, a 96-byte block and a 32-byte block. The 96-byte block becomes block p3, and the 32-byte block sits around waiting for somebody to ask for 32 bytes (which never happens).

http://blogs.msdn.com/b/oldnewthing/archive/2010/04/29/10004218.aspx?PageIndex=2

4. Low-fragmentation heap in Visual Studio 2010 and Windows Vista/7

Generally speaking, the low-fragmentation heap works pretty well for most classes of applications, and you should consider using it. (In fact, I'm told that the C runtime libraries have converted the default C runtime heap to be a low-fragmentation heap starting in Visual Studio 2010.)

http://blogs.msdn.com/b/oldnewthing/archive/2010/04/29/10004218.aspx

Starting with Windows Vista, the system uses the low-fragmentation heap (LFH) as needed to service memory allocation requests. Applications do not need to enable the LFH for their heaps.

http://msdn.microsoft.com/en-us/library/aa366750%28VS.85%29.aspx

http://www.89teen.com

Why the low fragmentation heap (LFH) mechanism may be disabled on some computers that are running Windows Server 2003, Windows XP, or Windows 2000
http://support.microsoft.com/kb/929136

Chris Valasek, Understanding the Low-Fragmentation Heap: From Allocation to Exploitation
http://www.blackhat.com/html/bh-us-10/bh-us-10-briefings.html#Valasek
http://illmatics.com/Understanding_the_LFH.pdf

Kategorie:

Czytaj dalej wpis Heap fragmentation and Low-fragmentation Heap
Blog
277 odsłon

Mark's Russinovich presentations from the 2010 Professional Developer's Conference

published by Kuling on sob., 2010-11-13 16:58

If you want to know the difference between System Committed memory and Process Committed memory, wondered what all those memory numbers shown by Task Manager really mean, or want to gain insight into the memory-related impact of a process, then this talk is for you. Using various memory analysis tools including: Process Explorer, VMMap, RAMMap, and others to highlight concepts throughout, the presentation starts with an overview of virtual memory management, describing types of process address space memory and how they impact system virtual memory. Then it dives into physical memory management, discussing how Windows manages process working sets, how it keeps track of physical memory, and how memory moves between different states.

Mysteries of Windows Memory Management, Part 1
Mysteries of Windows Memory Management, Part 2

Kategorie:

Programowanie

Windows

Standing on the shoulders of the blue monster - Hardening Windows applications

published by Kuling on wt., 2010-08-10 13:28

Cytat:

Microsoft has implemented lots of useful functionality in Windows that they use in their own products. Many of these features can be used to enhance the security of third party applications, but not many developers or software architects know about them. This talk will detail some of the technical underpinnings of Windows features like UAC, IE protected mode and Terminal Serivces and show how they can be used to defend your own software from attack.

https://media.blackhat.com/bh-us-10/presentations/olleb/BlackHat-USA-2010-olleb-Hardening-Windows-Applications-slides.pdf http://www.blackhat.com/html/bh-us-10/bh-us-10-archives.html

Kategorie:

Fault Tolerant Heap

published by Kuling on śr., 2010-01-27 14:20

http://channel9.msdn.com/shows/Going+Deep/Silviu-Calinoiu-Inside-Windows-7-Fault-Tolerant-Heap/

http://msdn.microsoft.com/en-us/library/dd744764%28VS.85%29.aspx

Kategorie:

C++

Programowanie

Windows

The alertable wait / APC

published by Kuling on wt., 2009-12-29 15:31

Cytat:

SleepEx(INFINITE, TRUE);

http://blogs.msdn.com/oldnewthing/archive/2006/05/03/589110.aspx

Kategorie:

Concurrency

Programowanie

Windows

Czytaj dalej wpis The alertable wait / APC
Blog
274 odsłony

WINDOWS NT - THREAD SCHEDULER

published by Kuling on pon., 2009-10-12 15:55

http://students.mimuw.edu.pl/SO/Projekt05-06/temat1-g7/winnttsched.pdf

Kategorie:

Concurrency

Programowanie

Windows

Czytaj dalej wpis WINDOWS NT - THREAD SCHEDULER
Blog
276 odsłon

Multithreaded File I/O

published by Kuling on pon., 2009-09-28 19:45

Cytat:

What This All Means
Overall, the results show that multithreaded file I/O can both improve or decrease performance significantly. Keep in mind that an application typically does not only read data, but also processes the data read in a more ore less CPU-intensive way. This leads to different results for every application and even tasks within a application. This also may or may not be the case for writing data. Furthermore, there are very different ways in how and when files will be read or written, as well as different hardware and software configurations that a application will meet. There is no general advice software developers can follow. For example, in one application I measured clearly that using multiple threads per sequential read file increased performance significantly in the 64-bit version. But with the 32-bit version more threads decreased performance on the same machine, the same operating system (Windows XP x64) and the same source code. In another case, where an application opened and appended thousands of files, the best solution was to create 8 threads that did nothing but close files (on a average dual-core machine).

http://www.ddj.com/cpp/220300055?pgno=2

Kategorie:

Concurrency

Programowanie

Windows