Archive for January, 2010

Reasoning with a Bug

Sunday, January 31st, 2010

If those bugs had been around for hundreds of millions of years before evolution climbed mount improbable to design human species does it mean that software bugs came before intelligent software? :-)

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Bugtation No.111

Sunday, January 31st, 2010

Software “bugs have been around for” decades.

A bugtated quotation from one website dedicated to bed bugs

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Bugtation No.110

Sunday, January 31st, 2010

Debugging at large. Remember those bugs from The Day Earth Stood Still movie that were nicely deactivated at once? Remember Nobel Laureate Professor Barnhardt was threading with Klaatu over the correct version of General Relativity on a blackboard and then at once realized that he was talking to an alien? His next phrase was the one that I repeat every day (and I also listen to Bach every day):

“I have so many questions to ask” this memory dump.

The Day the Earth Stood Still (2008 film)

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Structure and Noise

Friday, January 29th, 2010

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Mode-independent WinDbg scripts

Friday, January 29th, 2010

These are scripts that can be run without modification in both user and kernel modes to collect information from user and kernel spaces. For example, we want to collect thread stack traces for CARE system and we have different kinds of memory dumps stored on our computer. There is no a single command that can show stack traces for all threads in a process and kernel / complete memory dumps. However, we can combine separate mode-sensitive commands in one script:

.kframes 1000
!for_each_thread !thread @#Thread 1f
~*kv

The first command eliminates the common mistake of truncated traces. The second command fails for process user memory dumps but shows full 3-parameter stack trace for every thread in a system including user space thread stack counterpart for complete memory dumps after switching to the appropriate process context if any. The third command fails for kernel and complete memory dumps but lists stack traces for each thread in a process user memory dump. Therefore, we have just one script that we can run against all memory dumps.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -  

Debugger’s Screen Resolution

Wednesday, January 27th, 2010

What screen resolutions do debuggers use? Google analytics provides statistics for 2009. 1,071 different screen resolutions were used (I guess this diversity comes from multi-monitor configurations and PDA) with top 10:

Clearly old 800×600 is in minority today. There were lucky debuggers with 5120×1024 (128-bit ready for wider stack traces?) and 3840×2100 (I need more book sales for that) and even someone with screen resolution 0×0 viewed the content 12 times.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Operating Systems Scene: The View from DumpAnalysis.org

Wednesday, January 27th, 2010

Highly predictable picture from Google analytics of OS used to view portal and blog content:

One of the goals is to increase non-Windows OS presence over the next few years.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Internet Browsers Scene: The View from DumpAnalysis.org

Wednesday, January 27th, 2010

I was curious to see what browsers are used to view portal and blog content and Google analytics provided me statistics for 2009 (there is about 9% decline in IE variants compared to 2008). 62 “different” browsers viewed content with the top 10 (I actually expected more for IE and was surprised with statistics):

Some strange browser names below perhaps point to some sort of memory corruption :-) 

1. Internet Explorer
2. Firefox
3. Chrome
4. Opera
5. Safari
6. Mozilla
7. Mozilla Compatible Agent
8. SeaMonkey
9. Konqueror
10. BlackBerry8900
11. Opera Mini
12. Camino
13. IE with Chrome Frame
14. (not set)
15. Lynx
16. Netscape
17. Googlebot
18. BlackBerry9630
19. Playstation
20. BlackBerry9530
21. -^_^- Hello :)
22. <?echo ‘<pre>’; system
23. BlackBerry9000
24. Lunascape
25. NetFront
26. Unsupported Browser Version
27. 12345
28. Empty
29. Playstation Portable  2
30. SAMSUNG-SGH-I617  2
31. —
32. 31337′
33. 8900b
34. <?include
35. <script>alert
36. BlackBerry9500
37. Blazer
38. GOOGLEBOT
39. General Browser
40. HTC_P3490 Opera
41. HTC_Touch_HD_T8282 Opera
42. HTC_Touch_Pro2_T7373 Opera
43. HTC_Touch_Pro_T7272 Opera
44. Hellbrowser 6.66
45. Helyi user agent
46. IE 8
47. Midori
48. NCSA Mosaic
49. NightDynamo AdminPanel v0.2.1
50. NokiaE71-2;Mozilla
51. NokiaNokia 6210s
52. PPC; 240×320; HTC_P3450
53. SAMSUNG-SGH-I637
54. Samsung-SPHM540 Polaris
55. SonyEricssonK750
56. Uzbl
57. Yahoo! Slurp
58. holy_teacher FirePHP
59. mozilla
60. pippos.7
61. tdhbrowser
62. unknown

Here is the distribution of IE versions for 2009:

 

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Operating Closure of Memory (Categories for the Working Software Defect Researcher, Part 2)

Tuesday, January 26th, 2010

In part 1 we defined MemP category and the operating field of a pointer as its link to a memory location it is pointing to. This operating field value can be in a different pseudo-memory plane if its value is outside memory bounds, for example, 8FFFFFF0 for a memory with the highest possible address 7FFFFFFF:

 

We define the closure of memory as the smallest MemP category that includes memory for operating fields of every pointer for the current memory snapshot. For example above, by adding another memory location that has a pointer value pointing back to the original memory region we have the following operating closure:

  

We can also add more memory as well:

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Bug-sistential and Bug-sistentialism (Debugging Slang, Part 6)

Tuesday, January 26th, 2010

Bug-sistential - pertaining to existing bugs
Bug-sistentialism - a pessimistic outlook about the existence of bugs

Examples: What a bug-sistential problem we have to solve here! Pure bug-sistentialism!

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Bugtation No.109

Tuesday, January 26th, 2010

Symmetrical bugtation:

Delusion of “difference and repetition” in debugging.

Gilles Deleuze, Difference and Repetition

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Workaround Patterns (Part 3)

Tuesday, January 26th, 2010

What happens when Hidden Output and Frozen Process patterns don’t help with annoying popup windows? The former can’t prevent windows from reappearing afresh and the latter could block other coupled processes that might exchange window messages with our suspended process or simply use any IPC mechanism. Here Axed Code pattern can help as demonstrated below. One process was frequently and briefly showing network disconnection message box or dialog. The problem is that it was also bringing its main window into foreground disrupting work in other windows because they were loosing focus. Next time the dialog appeared we found its process ID in Task Manager and attached WinDbg to it. We wasn’t sure what dialog function to intercept so we put a general breakpoint on all “Dialog” functions for all threads:

0:000:x86> bm *Dialog*
[...]
  6: 73a8ba81 @!"MFC80!CDialog::~CDialog"
  7: 73ac25e2 @!"MFC80!CPageSetupDialog::~CPageSetupDialog"
  8: 73a94b6b @!"MFC80!CDHtmlDialog::_AfxSimpleScanf"
  9: 73a8fbe9 @!"MFC80!CFileDialog::OnTypeChange"
 10: 73a90b17 @!"MFC80!CColorDialog::GetRuntimeClass"
 11: 73a8bb4a @!"MFC80!CDialog::CreateIndirect"
[...]
360: 73a93750 @!"MFC80!CDHtmlDialog::OnNavigateComplete"
361: 73a8f1f3 @!"MFC80!CCommonDialog::OnOK"
362: 73a95d9f @!"MFC80!CDHtmlDialog::GetDropTarget"
363: 73a90266 @!"MFC80!CPrintDialog::GetDevMode"
364: 73ac1514 @!"MFC80!COleInsertDialog::COleInsertDialog"
365: 73ac27c7 @!"MFC80!COlePropertiesDialog::COlePropertiesDialog"
366: 73a75282 @!"MFC80!CWnd::UpdateDialogControls"
367: 73a7fd86 @!"MFC80!CDialogBar::SetOccDialogInfo"

0:000:x86> g
Breakpoint 314 hit
MFC80!_AfxPostInitDialog:
73a7134e 55              push    ebp

0:000:x86> kL 100
ChildEBP RetAddr  Args to Child             
0027ed2c 73a7180a MFC80!_AfxPostInitDialog
0027ed90 75628817 MFC80!_AfxActivationWndProc+0x90
0027edbc 7562898e USER32!InternalCallWinProc+0x23
0027ee34 7562c306 USER32!UserCallWinProcCheckWow+0x109
0027ee78 756375a2 USER32!SendMessageWorker+0x55b
0027ef4c 7563787a USER32!InternalCreateDialog+0xb64
0027ef70 75649b65 USER32!CreateDialogIndirectParamAorW+0x33
0027ef9c 75225192 USER32!CreateDialogParamA+0x4a
WARNING: Stack unwind information not available. Following frames may be wrong.
0027efc8 010c3bf1 DllA!WarningPopup+0×152
0027effc 73a71812 ProcessA+0×9fa1
00000000 00000000 MFC80!_AfxActivationWndProc+0×98

Now we cleared all breakpoints and put the new breakpoint on WarningPopup function:

0:000:x86> bc *

0:000:x86> bp DllA!WarningPopup

0:000:x86> g
Breakpoint 0 hit
DllA!WarningPopup:
75225040 51              push    ecx

Then we assumed that the calling convention was the default one used by C or C++ code like _cdecl and took the bold step to replace push ecx with ret instruction:

0:000:x86> a 75225040
75225040 ret
ret
75225041

0:000:x86> g
Breakpoint 0 hit
DllA!WarningPopup:
75225040 c3 ret

0:000:x86> bc *

0:000:x86> g

Result: no warning popups anymore.

I originally intended to name the pattern Patched Code but then realized that code axing can also be done at the source code level as a quick temporal fix.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Workaround Patterns (Part 2)

Monday, January 25th, 2010

Another workaround pattern for some problems is to freeze a process responsible for an annoying or excessive activity like in the case study: Debugger as a Shut Up Application. We can also use other tools for this purpose like Mark Russinovich’s PsSuspend. The suitable name for this pattern is Frozen Process.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Reading Notebook: 25-January-10

Monday, January 25th, 2010

Comments in italics are mine and express my own views, thoughts and opinions

Windows Internals by M. Russinovich, D. Solomon and A. Ionescu:

Kernel Process variables (p. 343)

0: kd> !process poi(PsIdleProcess)
PROCESS fffff800019910c0
SessionId: none  Cid: 0000    Peb: 00000000  ParentCid: 0000
DirBase: 00124000  ObjectTable: fffff88000000080  HandleCount: 606.
Image: Idle
VadRoot fffffa8003b97c70 Vads 1 Clone 0 Private 1. Modified 0. Locked 0.
DeviceMap 0000000000000000
Token                             fffff88000003330
ElapsedTime                       00:00:00.000
UserTime                          00:00:00.000
KernelTime                        00:00:00.000
QuotaPoolUsage[PagedPool]         0
QuotaPoolUsage[NonPagedPool]      0
Working Set Sizes (now,min,max)  (6, 50, 450) (24KB, 200KB, 1800KB)
PeakWorkingSetSize                6
VirtualSize                       0 Mb
PeakVirtualSize                   0 Mb
PageFaultCount                    1
MemoryPriority                    BACKGROUND
BasePriority                      0
CommitCharge                      0

        THREAD fffff80001990b80  Cid 0000.0000  Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 0
Not impersonating
DeviceMap                 fffff88000007310
Owning Process            fffff800019910c0       Image:         Idle
Attached Process          fffffa8003bf1040       Image:         System
Wait Start TickCount      16021          Ticks: 13224 (0:00:03:26.295)
Context Switch Count      142852
UserTime                  00:00:00.000
KernelTime                00:06:13.700
Win32 Start Address nt!KiIdleLoop (0xfffff80001876880)
Stack Init fffff80002bdadb0 Current fffff80002bdad40
Base fffff80002bdb000 Limit fffff80002bd5000 Call 0
Priority 16 BasePriority 0 PriorityDecrement 0 IoPriority 0 PagePriority 0
Child-SP          RetAddr           Call Site
fffff800`02bdad80 fffff800`01a43860 nt!KiIdleLoop+0x11b
fffff800`02bdadb0 00000000`00000000 nt!zzz_AsmCodeRange_End+0x4

        THREAD fffffa60005f5d40  Cid 0000.0000  Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 1
Not impersonating
DeviceMap                 fffff88000007310
Owning Process            fffff800019910c0       Image:         Idle
Attached Process          fffffa8003bf1040       Image:         System
Wait Start TickCount      0              Ticks: 29245 (0:00:07:36.224)
Context Switch Count      162365
UserTime                  00:00:00.000
KernelTime                00:06:14.808
Win32 Start Address nt!KiIdleLoop (0xfffff80001876880)
Stack Init fffffa600191bdb0 Current fffffa600191bd40
Base fffffa600191c000 Limit fffffa6001916000 Call 0
Priority 16 BasePriority 0 PriorityDecrement 0 IoPriority 0 PagePriority 0
Child-SP          RetAddr           Call Site
fffffa60`0191bd80 fffff800`01a43860 nt!KiIdleLoop+0x11b
fffffa60`0191bdb0 00000000`00000000 nt!zzz_AsmCodeRange_End+0x4

Relevant process functions (pp. 344 - 345) - More of them can be found here: http://msdn.microsoft.com/en-us/library/ms684847(VS.85).aspx

Protected processes (pp. 346 - 348) - It can be seen in _EPROCESS block (the output taken from a complete memory dump):

0: kd> dt _EPROCESS fffffa8004b5e040
ntdll!_EPROCESS
[...]
+0x36c ProtectedProcess : 0y1
[...]

The following script lists protected processes on W2K8:

0: kd> !for_each_process "dt _EPROCESS ImageFileName @#Process; dt _EPROCESS ProtectedProcess @#Process"
ntdll!_EPROCESS
+0x238 ImageFileName : [16]  "System"
ntdll!_EPROCESS
+0x36c ProtectedProcess : 0y1
[...]
ntdll!_EPROCESS
+0x238 ImageFileName : [16]  "audiodg.exe"
ntdll!_EPROCESS
+0x36c ProtectedProcess : 0y1
[...]

System process is protected because of Ksecdd.sys stores info in user space (p. 347)

PROCESS_QUERY_LIMITED_INFORMATION (p. 347)

Access violation by design for Protected Media Path processes when a kernel-mode debugger is enabled (p. 348) - this is not an optimal design in my opinion - I had problems with that: http://www.dumpanalysis.org/blog/index.php/2010/01/08/live-kernel-debugging-of-a-system-freeze-case-study/. The better way is to show a message box and gracefully exit and only emit AV if message box is bypassed. 

 

Advanced .NET Debugging by M. Hewardt:

PE format and its relation to .NET (pp. 26 - 27)

AddressOfEntryPoint (pp. 28 - 29 and p. 31) - we can also use !dh command to find that address (similar to what dumpbin.exe does):

0:001> lm m notepad
start             end                 module name
00000000`ff180000 00000000`ff1af000   notepad    (deferred)        

0:001> !dh 00000000`ff180000
[...]
OPTIONAL HEADER VALUES
20B magic #
8.00 linker version
E400 size of code
1CC00 size of initialized data
0 size of uninitialized data
D1B4 address of entry point
1000 base of code
—– new —–
00000000ff180000 image base
1000 section alignment
200 file alignment
2 subsystem (Windows GUI)
6.00 operating system version
6.00 image version
6.00 subsystem version
2F000 size of image
400 size of headers
32C26 checksum
[…]

0:001> u 00000000`ff180000+D1B4
notepad!WinMainCRTStartup:
00000000`ff18d1b4 4883ec28        sub     rsp,28h
00000000`ff18d1b8 e88b020000      call    notepad!_security_init_cookie (00000000`ff18d448)
00000000`ff18d1bd 4883c428        add     rsp,28h
00000000`ff18d1c1 e9b6fcffff      jmp     notepad!IsTextUTF8+0xc0 (00000000`ff18ce7c)
00000000`ff18d1c6 cc              int     3
00000000`ff18d1c7 cc              int     3
00000000`ff18d1c8 cc              int     3
00000000`ff18d1c9 cc              int     3

Application domains in ASP.NET; 3 default app domains (system, shared, default) in normal app (p. 34)

!dumpdomain SOS command (pp. 35 - 36)

Low(High)FrequencyHeap and StubHeap (p. 36) - Looks like they are not normal heaps or heap segments. I plan to test all commands on x64 .NET:

0:003> !dumpdomain
--------------------------------------
System Domain: 000007fef15a8ef0
LowFrequencyHeap: 000007fef15a8f38
HighFrequencyHeap: 000007fef15a8fc8
StubHeap: 000007fef15a9058
Stage: OPEN
Name: None
--------------------------------------
Shared Domain: 000007fef15a9860
LowFrequencyHeap: 000007fef15a98a8
HighFrequencyHeap: 000007fef15a9938
StubHeap: 000007fef15a99c8
Stage: OPEN
Name: None
Assembly: 0000000000372d10
--------------------------------------
Domain 1: 0000000000360840
LowFrequencyHeap: 0000000000360888
HighFrequencyHeap: 0000000000360918
StubHeap: 00000000003609a8
Stage: OPEN
SecurityDescriptor: 00000000003630e0
Name: TestCLR.exe
[...]

Workaround Patterns (Part 1)

Sunday, January 24th, 2010

After fighting HTML comments in Safari and Chrome (see the case study below) I came to an idea to name and catalog workaround patterns in troubleshooting and debugging. The first one is called Hidden Output. Sometimes we can just remove message boxes reporting minor problems and generating unnecessary support calls by hiding their windows, for example, by using CtxHideEx32. A different example is what I did today when troubleshooting Amazon aStore widget HTML code. It worked well in IE8:

However, in Apple Safari and Google Chrome the widget code was visible at the top of the page:

 

After a few unsuccessful attempts to debug the problem and faced with other pressing tasks I got a flash in my mind to hide the visible code by changing its color to be the same as its background:

<font color=”D3E7F4″><script type=”text/javascript”><!–
amazon_ad_tag=”crasdumpanala-20″;
amazon_ad_width=”728″;
amazon_ad_height=”90″;
amazon_color_background=”D3E7F4″;
amazon_color_border=”0000FF”;
amazon_color_logo=”FFFFFF”;
amazon_color_link=”0000FF”;
amazon_ad_logo=”hide”;
amazon_ad_link_target=”new”;
amazon_ad_border=”hide”;
amazon_ad_title=”OpenTask Books, Magazines and Notebooks”; //–></script>
<script type=”text/javascript” src=”http://www.assoc-amazon.com/s/asw.js”></script></font>

 
After that the picture became nicer:

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Memuon: A Definition

Thursday, January 21st, 2010

What is that mysterious memory “particle” memuon? According to memoidealism our Universe has Memory (*) and therefore, its memory has to be composed from memory entities. These entities are called memuons and they can be represented as numbers (some extreme interpretation can be that memuons are numbers, similar to metaphysics of Pythagoreanism). There can be “heavy” memuons (for example, represented by a number that is a 64 TB memory dump; for dumps as numbers see the discussion about memorillions) and the “light” ones (for example, represented by a byte value numbers). There are no 2 distinct memuons with the same number representation. There is infinite amount of memuons and all of them can be put into a “Memorized” relation and ordering, for example:

M1 Σ M2 Σ M3 Σ … 

where the state of M1 can be memorized by M2, the state of M2 can be memorized by M3 and so on (**). Only memuon states can be memorized in other memuons. Memorization is not an inclusion, containment or aggregation. But any given memuon can be memorized many times and their memorized states will be identical when represented by numbers. For any given memuon the number of states of other memuons it can memorize is bounded. This is consistent with computer memory and its saving semantics, for example, we can save 8 bytes in a qword.

(*) Strong Memoidealism postulates that our Universe is Memory, the so called Memory Universe Hypothesis (MUH); see also EPOC hypothesis for Multiverse.

(**) Σ is 90° counterclockwise letter M.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Memoidealism Defined

Wednesday, January 20th, 2010

Memoidealism (or alternatively Panmemorism, not the same as Panpsychism) now acquires a definition motivated by the functional definition of panpsychism in David Skrbina’s book Panpsychism in the West:

Memoidealism

All entities, e.g. objects, components, subsystems and systems of objects and components, possess a memory for themselves.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Plans for The Year of Dump Analysis

Monday, January 18th, 2010

After exciting results of  the previous year of debugging it is time to announce modest plans for this year, 0×7DA:

Release the first beta version of EasyDbg

Release the first beta version of CARE (Crash Analysis Report Environment) for a pattern-driven debugger log analyzer with standards for structured audience-driven reports

Release the first beta version of STARE (Software Trace Analysis Report Environment) for a pattern-driven software trace analyzer with corresponding standards for structured audience-driven reports

Publish the following books on dump analysis that address different audiences (general users, system administrators, support and escalation engineers, testers, software engineers, security and software defect researchers):

Windows Debugging Notebook
Crash Dump Analysis for System Administrators and Support Engineers
- Memory Dump Analysis Anthology, Volume 4
- Memory Dump Analysis Anthology, Volume 5
- Memory Dump Analysis Anthology Color Supplement
- Principles of Memory Dump Analysis
- My Computer Crashes and Freezes: A Non-technical Guide to Software and Hardware Errors
- Linux, FreeBSD and Mac OS X Debugging: Practical Foundations
- Encyclopedia of Crash Dump Analysis Patterns
- WinDbg In Use: Debugging Exercises

Publish articles related to memory dump analysis in Debugged! magazine

Update WinDbg Poster and Cards

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Extending Multithreading to Multibraiding (Adjoint Threading)

Sunday, January 17th, 2010

Having considered computational threads as braided strings and after discerning several software trace analysis patterns (just the beginning) we can see formatted and tabulated software trace output in a new light and employ the “fabric of traces” and braid metaphors for an Adjoint Thread concept. This new concept was motivated by reading about Extended Phenotype (*) and extensive analysis of Citrix ETW-based CDF traces using CDFAnalyzer. The term Adjoint was borrowed from mathematics because the concept we discuss below resembles this metaphorical formula: (Thread A, B) = [A, Thread B]. Let me first illustrate adjoint threading using simplified trace tables. Consider this generalized software trace example (date and time column is omitted for visual clarity):

#

Source Dir

PID

TID

File Name

Function

Message

1

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

2

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

3

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

4

\src\lib

2792

5680

file2.cpp

barA

Message text…

5

\src\subsystemA

2792

5680

file1.cpp

fooA

Message text…

6

\src\subsystemA

2792

5676

file1.cpp

fooA

Message text…

7

\src\lib

2792

5680

file2.cpp

fooA

Message text…

8

\src\lib

2792

5680

file2.cpp

fooA

Message text…

9

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

10

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

11

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

12

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

13

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

14

\src\subsystemB

2792

3912

file3.cpp

barB

Message text…

15

\src\subsystemB

2792

2992

file4.cpp

fooB

Message text…

16

\src\subsystemB

2792

3008

file4.cpp

fooB

Message text…

We see several threads in a process PID 2792. In CDFAnalyzer we can filter trace messages that belong to any column and if we filter by TID we get a view of any Thread of Activity. However, each thread can “run” through any source directory, file name or function. If a function belongs to a library multiple threads would access it. This source location (can be considered as a subsystem), file or function view of activity is called an Adjoint Thread. For example, if we filter only subsystemA column in the trace above we get this table:

#

Source Dir

PID

TID

File Name

Function

Message

1

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

2

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

3

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

5

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

6

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

7005

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10198

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10364

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10417

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10420

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

10422

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

10587

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

10767

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

11126

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

11131

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

11398

\src\subsystemA

2792

5676

file1.cpp

fooA

Message …

11501

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

11507

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

11509

\src\subsystemA

2792

5664

file1.cpp

fooA

Message …

11513

\src\subsystemA

2792

5680

file1.cpp

fooA

Message …

11524

\src\subsystemA

2792

5668

file1.cpp

fooA

Message …

We can graphically view subsystemA as a braid string that “permeates the fabric of threads”:

We can get many different braids by changing filters, hence multibraiding. Here is another example of a driver source file view initially permeating 2 process contexts and 4 threads:

#

Source Dir

PID

TID

File Name

Function

Message

41

\src\sys\driver

3636

3848

entry.c

DriverEntry

IOCTL …

80

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

99

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

102

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

179

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

180

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

311

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

447

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

448

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

457

\src\sys\driver

2792

5108

entry.c

DriverEntry

IOCTL …

608

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

614

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

655

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

675

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

678

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

680

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

681

\src\sys\driver

3636

3896

entry.c

DriverEntry

IOCTL …

1145

\src\sys\driver

3636

4960

entry.c

DriverEntry

IOCTL …

1153

\src\sys\driver

3636

4960

entry.c

DriverEntry

IOCTL …

1154

\src\sys\driver

3636

4960

entry.c

DriverEntry

IOCTL …

(*) A bit of digression. Looks like biology keeps giving insights into software, there is even a software phenotype metaphor albeit a bit restricted to code, I just thought that we need also an Extended Software Phenotype.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

MDAAV1 and WDPF are the Most Gifted today

Friday, January 15th, 2010

Just noticed on Amazon tabs:

What is so special today? I come back to check again on 14th of February :-)

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -