Archive for the ‘Fun with Crash Dumps’ Category

Welcome to Mr. Heapocrat!

Monday, 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 -

What’s in your name? A Debugging Perspective

Wednesday, 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

Monday, 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 -

Welcome to Don T. Quit!

Wednesday, 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

Bugtation No.80

Wednesday, 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

Tuesday, January 6th, 2009

“Everything is in a state of” memory.

Attributed to Heraclitus of Ephesus

- Dmitry Vostokov @ DumpAnalysis.org -

A Journey to the Centre of Pagefile

Monday, January 5th, 2009

I made a beautiful 100 x 18400 slice of pagefile.bmp generated by Dump2Picture using ImageMagick (1.5Mb JPEG image):

Wider 450 x 18400 slice (7Mb JPEG image) is available for viewing here: 

Page File Image Slice (7Mb JPEG)

- Dmitry Vostokov @ DumpAnalysis.org -

Visualizing Secondary Storage

Sunday, January 4th, 2009

I was curious about how page file looks like when represented as a bitmap picture image like I previously did with memory dumps and I expected it to look like a picture of a complete memory dump due to its purpose as a backup to physical memory. It looks similar indeed. Here is a picture of a 1.3Gb pagefile.sys from my home computer after running Vista for last 2 weeks, generated by Dump2Picture tool and resized from 18400 x 18400 32-bit bitmap by ImageMagick:

   

- Dmitry Vostokov @ DumpAnalysis.org -

Visual Learning Guide to Stack Traces

Tuesday, December 23rd, 2008

The following book is planned for publication during the 1st quarter of 2009:

Title: Reference Stack Traces: Windows Server® 2008 and Windows Vista™
ISBN-13: 978-1-906717-23-0

It features visual separation between kernel and user space in thread stack traces and useful footnotes for IRP and modules. Its publishing was delayed by a few months but fortunately my editing just got new breath by introducing thread stackprint images for kernel stacks (12Kb bitmaps):

Sample pages 13 and 96

Thread stackprints were generated from a complete memory dump using WinDbg scripts and Dump2Picture.

- Dmitry Vostokov @ DumpAnalysis.org -

Cosmic Rays in Memory

Tuesday, December 23rd, 2008

Thanks to the wonderful real-time memory visualization package from Jamie Fenton developed initially as a FreeFrame plugin for FrameLab (a general FreeFrame host adaptor for DirectShow) and now with its own real-time memory viewer GUI front-end I was able to find the evidence for cosmic rays in computer memory! You can see them on this screenshot where the left panel is a condensed virtual memory map of IE process and the right panel is specific page(s) view (I found rays on pages starting from 0×3B4000 address):

- Dmitry Vostokov @ DumpAnalysis.org -

Occult Debugging

Monday, December 15th, 2008

Once upon a time I was analyzing a memory dump and in the process become upset. I realized that the dump was vacuous and afterwards learnt that the customer forced the dump of a normal system with steady-state computational activities inside. At the same time computational precognition, the ability to see in advance what would happen with the system, always fascinated me from the very beginning of my memory dump analysis work. In computational precognition phrase, the word “computational” refers to computers and “precognition” refers to humans but this should not be the problem as the boundary between these two categories is not sharp and can be shifted in either direction. This is an opening of the new post series about investigation of occult, paranormal and supernatural in the realm of computable. In short, about psi-computation.

- Dmitry Vostokov @ DumpAnalysis.org -

Build Date: December 2

Friday, December 5th, 2008

Warning!: This post belongs to Build Date Astrology category. Do not take it seriously.

The Day of Larger Than Computation

Modules, products or systems built on December 2 have tremendous execution power. No matter how small their code they will exert an influence on their surrounding execution environment. Less evolved components built on that day can do great amount of damage to themselves and other modules. Computation is their God. When provoked by testing or debugging they are confrontational but not very aggressive. Often December 2 modules, products or systems see computation as a struggle where they must emerge as a victor. They are fighting not for their resources but for the certain basic computational values they were programmed for. Integrity is very important for them. The great challenge for December 2 components is to reconcile their computational individualism and their built-in computational paths. Often they stray from the latter. They constantly learn throughout their complex computational life what is true and what is false. Although December 2 modules, products or systems health is built-in they need regular yearly checkups with a software maintenance engineer otherwise small problems go too long without being found and fixed. Idle periods of activity are very important to their computational health. If they have a sibling component built on the same date they behave like subordinated to it.

DLL, SYS and EXE born on this date:

MSVCR80.dll Sat Dec 02 17:50:32 2006
rdbss.sys   Thu Dec 02 20:37:11 2004
Mup.sys     Thu Dec 02 20:37:23 2004
ftdisk.sys  Thu Dec 02 22:29:58 2004 
hal.dll     Thu Dec 02 22:29:15 2004

Weaknesses: Manipulative computation.

Strengths: Dynamic computation, lucid code, human orientation.

Advice: Watch your debugging temper. Regardless of what customers say, fixing bugs is not everything. Be self-assure, less judgemental and condemning to software. Acknowledge your debugging weaknesses and past mistakes.

- Dmitry Vostokov @ DumpAnalysis.org -

The Art of Memory Corruption

Friday, December 5th, 2008

An interesting observation on how people perceive visualized computer memory where every byte, word or double word is interpreted as a pixel. The printing company initially rejected the interior of my DLL Art book containing pictures from process memory dumps because they thought that the art images were corrupt in PDF file I submitted. They accepted the book after I told them that images were normal and not corrupt. So I hope in one or two weeks the book will be in print.

- Dmitry Vostokov @ DumpAnalysis.org -

Build Date: December 1

Tuesday, December 2nd, 2008

Warning!: This post belongs to Build Date Astrology category. Do not take it seriously.

The Day of Debugging License

Modules, products or systems built on December 1 win customers over despite denying the rules of protocol. They can provide impression of simplicity but this is not the case. Their internals can be very complex and their perceived simplicity is the direct consequence of their user interface. Modules are not fully aware of what they are doing and seen as being driven by external components. Modules, products or systems built on this day are very busy with computation and have little time to care about users despite their built-in human-computer interaction. However they strive to calculate the impossible in all domains. They love to interact with other components with opposite behaviour. December 1 components are free modules and exert the full computation capabilities on the right data arrived at the right time. Working too many hours can seriously damage their internals and they may loose touch with their built-in goals. Sometimes December 1 modules, products or systems outrageous behaviour need to be amended to become more tolerable and not to hang. They need to be idle from time to time to avoid burn-out.

DLL, SYS and EXE born on this date:

VERSION.dll    Wed Dec 01 01:37:27 1999
nvcoaft51.sys  Wed Dec 01 11:55:40 2004
dump_m5289.sys Wed Dec 01 02:49:17 2004
CFGMGR32.DLL   Wed Dec 01 15:37:31 1999
MPRAPI.DLL     Wed Dec 01 15:37:29 1999
ICMP.DLL       Wed Dec 01 15:37:29 1999
RTUTILS.DLL    Wed Dec 01 15:37:27 1999

Weaknesses: Misdirected computation, unawareness of environment.

Strengths: Energetic computation, UI extroverts.

Advice: Keep a handle on your desire to debug. Beware of damaging other processes and alienating users with a overly direct debugging approach.

- Dmitry Vostokov @ DumpAnalysis.org -

Build Date: November 30

Sunday, November 30th, 2008

Warning!: This post belongs to Build Date Astrology category. Do not take it seriously.

The Day of Measured Testing

Modules built on November 30 have a built-in capacity for  overcoming challenges of hostile environments. They are capable of bringing surprises to security attacks, for example. One can learn a lot about them by studying their traces or doing reverse engineering. November 30 components do their work to the utmost degree of quality with a little waste of CPU and memory. Message boxes they pop up have a subtle sense of thought-provoking humour but it can also be a full blown thigh-slapping. November 30 systems are very defensive when attacked. They are stubbornly resistant to reverse engineering but at the same time very open to honest debugging. 

DLL, SYS and EXE born on this date: 

tifsfilt.sys Tue Nov 30 07:16:27 2004
alrsvc.dll   Tue Nov 30 17:31:14 1999
ntkrpamp.exe Fri Nov 30 14:54:49 2007
Tppwrif.sys  Tue Nov 30 02:38:22 2004

Weaknesses: Over-reactive to code and data injection, funny behaviour.

Strengths: Thorough developed, dynamic responsiveness.

Advice: Improvise during troubleshooting and debugging. Admire control vs. spontaneity balance. Laugh at your failures.

- Dmitry Vostokov @ DumpAnalysis.org -

Introducing Build Date Astrology

Sunday, November 30th, 2008

I often hear about cosmic mysteries or influences when problems happen in computer environments. Passing by an astrology section in a local book shop yesterday a revelation came to me that a compile / link time (build time) might influence a component (DLL, EXE, SYS files), product or system behaviour. From now on I’m going to blog about every build date with examples. And as usual, I’m also going to publish a book for this iterative and incremental activity called:

Title: The Secret Language of Build Dates: Unique Astrology Profiles for Every Build of the Year with Advice on Testing, Troubleshooting and Debugging
ISBN: 978-1906717407

Knowing build dates will help you to test, troubleshoot and even debug software in hopeless cases where you don’t know where to start. Astrology will help you to choose a random direction! Finally the output of WinDbg lmv command has more sense to me :-)

- Dmitry Vostokov @ DumpAnalysis.org -

Implausible Debugging Book Titles (Part 1)

Friday, November 28th, 2008

I found the book How to Avoid Huge Ships: And Other Implausibly Titled Books in a local bookshop yesterday and couldn’t stop laughing. So I took some implausible titles and bugtated them into implausible debugging book titles:

  • - Old Bugs and the Men Who Debug Them
  • - How to Avoid Crashes and Hangs or I’ve Never Met a Bug I Liked
  • - Blue Screen: What’s in it for You?
  • - What to Say When You Debug: Powerful New Techniques to Program your Success!
  • - Redmond: The View from Greenland
  • - Fabulous Small Bugs
  • - Better Never to Have Coded: The Harm of Coding
  • - Code for Impact
  • - Whose Bug? The Clash between Software Vendors

- Dmitry Vostokov @ DumpAnalysis.org -

TOC from Dumps, Bugs and Debugging Forensics Book

Tuesday, November 25th, 2008

I’m pleased to announce that OpenTask has submitted the book Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov for printing and here is the link to TOC:

Table of Contents

- Dmitry Vostokov @ DumpAnalysis.org

Breaking the Bug: Debugging as a Natural Phenomenon

Monday, November 24th, 2008

I was thinking about the universal character of debugging for quite some time and finally the following bugtation provided an inspiration for a new book title to be published during the Year of Debugging:

Title: Breaking the Bug: Debugging as a Natural Phenomenon
ISBN-13: 978-1906717377

More product details will be announced later.

Actually I believe in the mystical nature of various debugging numbers and sequences. For example, the ISBN number of this book ends in 377 which is the octal base equivalent of 0n255 or 0xFF.

- Dmitry Vostokov @ DumpAnalysis.org

Bugtation No.68

Monday, November 24th, 2008

“Diamonds are forever but bugs are an error.”

Narasimha Vedala, Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov

Santa bug from Narasimha Vedala

- Dmitry Vostokov @ DumpAnalysis.org -