Vector Space Chemistry

January 23rd, 2009

I’ve been fascinated by Chemistry since the age of 13-14. At that time I noticed organic formulae on the blackboard of a higher school class and was curious about what they meant. So I asked my mother to bring me a book about Chemistry from a library and she brought a school textbook about Inorganic Chemistry. I read it in a few weeks and proceeded to reading a textbook about Organic Chemistry. At the same time I found in a local library 10 volumes of The Feynman Lectures on Physics (in Russian translation) and started reading the first volumes on classical mechanics and learnt about calculus. Another popular book about Quantum Chemistry raised my curiosity in Quantum Mechanics and Morris Kline’s The Loss of Certainty book (in Russian translation) made me interested in abstract mathematics and its logical and set-theoretical foundations including Gödel’s theorems and intuitionistic mathematics. All this happened before the age of 16 and in one evening when I was reading a Linear Algebra textbook an idea struck me to represent certain aspects of Inorganic Chemistry formalisms like Periodic Table and empirical formulas of chemical compounds as linear vector spaces of element vectors over the field of numbers.

Now OpenTask is going to publish its first popular science book called:

Vector Space Chemistry (ISBN: 978-1906717551) 

with a preface written after 25 years since the discovery of this mathematical model and formalization of Chemistry.

A note for cautious readers: I’m aware about over-excessive application of mathematics in sciences, especially after reading these books:

Fashionable Nonsense and Social Sciences as Sorcery

My book is just a popular science book that explains some chemical and abstract mathematical concepts and provides an example of using Mathematics as a modeling and formalization tool for Chemistry.

- Dmitry Vostokov @ DumpAnalysis.org -

Bugtation No.83

January 22nd, 2009

“Some” tester, “I believe, has said that true pleasure lies not in the discovery of” a bug, “but in the search for it.”

Lev Nikolayevich Tolstoy,
Anna Karenina

- Dmitry Vostokov @ DumpAnalysis.org -

Bugtation No.82

January 22nd, 2009

Not exactly about bugs:

“It is a terrible thing for” an engineer “to find out suddenly that all his life he has been” writing “nothing but the” code.

Oscar Wilde,
The Importance of Being Earnest

- Dmitry Vostokov @ DumpAnalysis.org -

Next Generation Memory Viewers

January 21st, 2009

DumpAnalysis.org team starts working on the next generation multi-monitor memory visualization framework utilizing DirectShow, Direct2D, Direct3D and DXGI technologies. Full system architecture and sample code for memory viewers using DirectShow technology will be featured in the forthcoming Computer Memory Visualization book.

- Dmitry Vostokov @ DumpAnalysis.org -

Welcome to Mr. Heapocrat!

January 19th, 2009

New word - new nickname…

Mr. Heapocrat is a member of a powerful group called heap class and a pseudonym for a historian and journalist that Debugged! MZ/PE magazine editorial board has invited to write a history and current affairs column called “Heap Inquiries”.

- Dmitry Vostokov @ DumpAnalysis.org -

Reviews of Hardware

January 16th, 2009

DumpAnalysis.org accepts hardware such as laptops for reviewing in relation to their suitability for extreme debugging, computer forensics, crash dump analysis and memory visualization. If you work for a H/W company like HP, Apple, Dell, Acer, Sony or any other respectable manufacturer please don’t hesitate to forward this post to your management: it could be your company brand or laptop model that debugging and software technical support community chooses next time of upgrade or for T&D / R&D! H/W reviews will be posted on the main portal page which currently has an audience of more than a hundred thousand unique visitors per year from more than 20,000 network locations (*).

If your company is interested please don’t hesitate to use this contact form:

http://www.dumpanalysis.org/contact

(*) From Google Analytics report.

- Dmitry Vostokov @ DumpAnalysis.org -

Updated Memory Timeline

January 16th, 2009

I’ve updated timeline widget with references to relevant blog posts and also added events that I forgot to add previously and ones that happened since my celebration of 5 years of memory dump analysis in October:

Memory Dump Analysis Portal Timeline

- Dmitry Vostokov @ DumpAnalysis.org -

Cover for Computer Memory Visualization Book

January 15th, 2009

Last weekend I spent a few hours devising a cover for the forthcoming computer memory visualization book and finally created this one piece cover featuring a journey to the center of pagefile theme and the discovery of cosmic rays in memory:

Coincidentally the whole 100 x 18400 centered slice of pagefile.sys image fit on the cover and nothing was left!

- Dmitry Vostokov @ DumpAnalysis.org -

What’s in your name? A Debugging Perspective

January 14th, 2009

An idea came from one of co-authors of a memory visualization book to interpret my name as Debug monitor interrupt __try (Dmitry) to remember correct spelling. As usual I generalize too much and propose to interpret other names from software and debugging perspective to unearth their hidden meaning:

Jeff (Jump exceptionally from fault) 

Serhat (Structured exception redirection handler trap) 

Sasha (Segment aligned structured handler)

Jamie (Jump across memory if exception)

More name interpretations are coming. Please don’t hesitate to send me yours. :-)

- Dmitry Vostokov @ DumpAnalysis.org -

Ethical Debugging

January 12th, 2009

While questioning current morally acceptable practices in relation to software I finally understood why I instinctively had never liked live debugging and preferred crash dump analysis instead. Because careless debugging with its destructive techniques was against my unconscious software ethical beliefs.

- Dmitry Vostokov @ DumpAnalysis.org -

Front Cover for DebugWare Book

January 10th, 2009

Finally designed a conceptual cover for DebugWare book using command-line theme:

- Dmitry Vostokov @ DumpAnalysis.org -

Where did the crash dump come from? (Part 2)

January 8th, 2009

Part 1 focused on using a debugger to extract a computer name from memory dumps. Here is a very simple approach for user dumps using built-in command line tools:

C:\UserDumps>findstr "COMPUTERNAME=" new_0200_2008-04-28_14-11-54-937_0cb0.dmp

Most of the time the last portion of output contains something like this:

..CommonProgramW6432=C:\Program Files\Common Files..COM
PUTERNAME=HOME-PC....ComSpec=C:\W2K3\system32\cmd.exe..
..♀.FP_NO_HOST_CHECK=NO...♂.HOMEDRIVE=C:......HOMEPATH=
\Documents and Settings\User...........................
.LOGONSERVER=\\SERVER..∩...NUMBER_OF_PROCESSORS=1...δ..
;..Φ;..╨α,.~........²²²²COMPUTERNAME=HOME-PC.²²²²

If we don’t see the variable we can redirect the output into a text file and look in it or simply open a dump in any hex editor and search for a UNICODE string.

- Dmitry Vostokov @ DumpAnalysis.org -

MDAA Variety on Creme and White Paper

January 8th, 2009

Which paper type do you prefer? Paperback Memory Dump Analysis Anthology volumes are printed on creme paper. Hardback volumes sold on Amazon are also printed on creme paper but Lulu uses white paper for them. Full color hardback Volume 1 Collector’s Edition is printed on white paper too and sold on Lulu only. I chose creme paper for Amazon and other distribution channels because I read that this type of paper is easier to read. So if you like text printed on white paper your only option at the moment is to buy a hardcover on Lulu.

Here is a stack of all different types of volumes:

From top to bottom:

  • - Paperback Volume 1 on crème paper (Lulu, Amazon, B&N, … )
  • - Hardcover Volume 2 on crème paper (Amazon, B&N, … )
  • - Paperback Volume 2 on crème paper (Lulu, Amazon, B&N, … )
  • - Hardcover Volume 1 on crème paper (Amazon, B&N, … )
  • - Hardcover Volume 1 on white paper (Lulu)
  • - Hardcover Volume 2 on white paper (Lulu)
  • - Hardcover Volume 1 Collector’s Edition on white paper (Lulu)

- Dmitry Vostokov @ DumpAnalysis.org -

Bugtation No.81

January 8th, 2009

“One must look for one” bug “only, to find many.”

Cesare Pavese, This Business of Living: Diaries 1935-1950

- Dmitry Vostokov @ DumpAnalysis.org -

Welcome to Don T. Quit!

January 7th, 2009

Debugged! MZ/PE magazine editorial board has secured a columnist Don T. Quit to write a column “Tips, Bits and Fields”. Don is very eager to offer a (socio- | psycho- | ε) logical advice to debugging community.

Just to remind that a deadline to submit articles for the first issue is set to 15th of February.

- Dmitry Vostokov @ DumpAnalysis.org

Book Review: Core Memory

January 7th, 2009

While working on “Computer Memory Visualization” book I noticed this recent title and immediately bought it:

Core Memory: A Visual Survey of Vintage Computers

Buy from Amazon

This is not only a wonderful hardcover coffee table book with stunning photographs of old computers and their memory hardware but also has numerous historical notes. It nicely complements my own DLL List Landscape: The Art from Computer Memory Space book that features virtual memory visual images.

- Dmitry Vostokov @ DumpAnalysis.org -

Bugtation No.80

January 7th, 2009

Originally I paid attention to “Paper is patient” in Social Sciences as Sorcery book. It merits its own bugtation:

Crash dump “is patient.”

German proverb

- Dmitry Vostokov @ DumpAnalysis.org -

Bugtation No.79

January 6th, 2009

“Everything is in a state of” memory.

Attributed to Heraclitus of Ephesus

- Dmitry Vostokov @ DumpAnalysis.org -

Bugtation No.78

January 6th, 2009

“For it is not enough to have a good” debugger: “one must use it well.”

René Descartes, Discourse on the Method

- Dmitry Vostokov @ DumpAnalysis.org -

Crash Dump Analysis Patterns (Part 13f)

January 5th, 2009

Sometimes there is not enough physical memory and the system experiences the so called disk or page file thrashing trying to resolve page faults. This can be seen in some memory dumps coming from frozen environments showing signs of double traps in running threads, the first one is a normal memory access fault (blue) and the other is forced NMI bugcheck to save a memory dump (red):

1: kd> .bugcheck
Bugcheck code 00000080
Arguments 004f4454 00000000 00000000 00000000

1: kd> !thread
THREAD 88939b20  Cid 360.378  Teb: 7ffdb000  Win32Thread: a20a7ac8 RUNNING
IRP List:
    86be9e68: (0006,0100) Flags: 00000070  Mdl: 00000000
    88939e68: (0006,0100) Flags: 00000070  Mdl: 00000000
    88939128: (0006,0100) Flags: 00000070  Mdl: 00000000
Not impersonating
Owning Process 889456e0
Wait Start TickCount    2357431       Elapsed Ticks: 9
Context Switch Count    18267                   LargeStack
UserTime                  0:00:08.0218
KernelTime                0:12:28.0109
Start Address KERNEL32!BaseThreadStartThunk (0x7c57b740)
Win32 Start Address msafd!SockAsyncThread (0x74fd3113)
Stack Init bef9e000 Current bef9db60 Base bef9e000 Limit bef9b000 Call 0
Priority 11 BasePriority 11 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr
8904aff0 80469211 hal!HalHandleNMI+0×193
8904aff0 80438621 nt!KiTrap02+0×41

bef9dc10 8043799a nt!MiTrimWorkingSet+0xa7
bef9dc38 804378ec nt!MiDoReplacement+0×2e
bef9dc50 804453cf nt!MiLocateAndReserveWsle+0×1e
bef9dc68 804444e0 nt!MiAddValidPageToWorkingSet+0×89
bef9dc8c 804443a2 nt!MiCompleteProtoPteFault+0xf6
bef9dcb8 804436e8 nt!MiResolveProtoPteFault+0×160
bef9dcfc 8044ccd0 nt!MiDispatchFault+0xfc
bef9dd4c 8046b063 nt!MmAccessFault+0xd1c
bef9dd4c 74fd31e0 nt!KiTrap0E+0xc7

016effb4 7c57b3bc msafd!SockAsyncThread+0xcd
016effec 00000000 KERNEL32!BaseThreadStart+0×52

If we check virtual memory stats we see the low number of available pages:

1: kd> !vm

*** Virtual Memory Usage ***
 Physical Memory:   524165   ( 2096660 Kb)
 Page File: \??\C:\pagefile.sys
    Current:   4190208Kb Free Space:   3298704Kb
    Minimum:   4190208Kb Maximum:      4190208Kb
 Page File: \??\E:\pagefile.sys
    Current:   4190208Kb Free Space:   3339860Kb
    Minimum:   4190208Kb Maximum:      4190208Kb
 Available Pages:     1098   (    4392 Kb)
 ResAvail Pages:    410646   ( 1642584 Kb)
 Modified Pages:    282384   ( 1129536 Kb)
 NonPagedPool Usage: 10046   (   40184 Kb)
 NonPagedPool Max:   68609   (  274436 Kb)
 PagedPool 0 Usage:  15391   (   61564 Kb)
 PagedPool 1 Usage:   1906   (    7624 Kb)
 PagedPool 2 Usage:   1925   (    7700 Kb)
 PagedPool 3 Usage:   1937   (    7748 Kb)
 PagedPool 4 Usage:   1892   (    7568 Kb)
 PagedPool Usage:    23051   (   92204 Kb)
 PagedPool Maximum:  87040   (  348160 Kb)
 Shared Commit:      16867   (   67468 Kb)
 Special Pool:           0   (       0 Kb)
 Free System PTEs:   65288   (  261152 Kb)
 Shared Process:     38655   (  154620 Kb)
 PagedPool Commit:   23051   (   92204 Kb)
 Driver Commit:       1060   (    4240 Kb)
 Committed pages:  1049592   ( 4198368 Kb)
 Commit limit:     2580155   (10320620 Kb)
[…]

In W2K dumps we can also see locking on a working set resource (I guess the name from Ws shortcut here):

 1: kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****

Resource @ nt!MmSystemWsLock (0×804869c0)    Exclusively owned
    Contention Count = 33083
    NumberOfExclusiveWaiters = 237
[…]

and huge number of threads in Ready state for every thread priority.

Looking at the current process owning the running thread shows the large number of page faults and increased kernel CPU time compared to time spent in user mode:

1: kd> !process 889456e0
PROCESS 889456e0  SessionId: 0  Cid: 0360    Peb: 7ffdf000  ParentCid: 01a8
    DirBase: 102af000  ObjectTable: 88945c08  TableSize: 622.
    Image: Application.EXE
    VadRoot 88944468 Clone 0 Private 838. Modified 30691412. Locked 188.
    DeviceMap 89049288
    Token                             e28db550
    ElapsedTime                       10:13:30.0684
    UserTime                          0:00:12.0578
    KernelTime                        0:12:38.0625
    QuotaPoolUsage[PagedPool]         31568
    QuotaPoolUsage[NonPagedPool]      68266
    Working Set Sizes (now,min,max)  (49, 50, 345) (196KB, 200KB, 1380KB)
    PeakWorkingSetSize                1956
    VirtualSize                       131 Mb
    PeakVirtualSize                   131 Mb
    PageFaultCount                    46180598
    MemoryPriority                    BACKGROUND
    BasePriority                      10
    CommitCharge                      1247

- Dmitry Vostokov @ DumpAnalysis.org -