Build Date: December 3
The Day of Troubleshooting Ingenuity
Modules, products or systems built on December 3 are ingenious in carrying out their computational plans. They can be secretive and computationally manipulative to achieve their goals. Components built on that day do not compute sellable data but produce side artifacts and therefore you may not make money from their computational abilities. Craftsman-like and creative code are their legacy. Often they process technical data and they do it as perfectionists. They prefer to do it alone, without constant approval from humans or other modules. Components, products or systems built on December 3 require high levels of privacy and at certain computational intervals might even require complete cut off of all their interfaces. They can achieve maximum throughput when they are alone. Their computational results seem inexplicable without the support of high CPU clock rates. Components built on that date tend to be cynical with data they process. However they may be caught up in their computation if they neglect self-maintenance. They were coded to work on certain goals and use certain tools but if they are coded to probe itself with the same computational intensity like they do with external data then they can achieve more quality of their work. Modules, products or systems built on December 3 often neglect self-maintenance and they are often carried away with their computational activities. Therefore they need regular checks from maintenance engineers because their original designers were architecturally oriented and not much informed about computational maladies.
DLL, SYS and EXE born on this date:
sptd.sys Sat Dec 03 08:59:59 2005
halmacpi.dll Fri Dec 03 04:29:15 2004
Mup.sys Fri Dec 03 04:37:23 2004
ftdisk.sys Fri Dec 03 04:29:58 2004
cdrbsvsd.sys Wed Dec 03 17:44:56 2003
rdbss.sys Fri Dec 03 12:37:11 2004
Weaknesses: Secretive and strange codes. Unapproachable from conventional troubleshooting and debugging methods.
Strengths: Concentrated on computational goals, innovative computation methods, craftsman-like code.
Advice: Delegate troubleshooting, testing and debugging responsibility to other engineers without worrying too much. Don’t be too reclusive when debugging. Maintain contact with people around you and show interest in personal development.
- Dmitry Vostokov @ SoftwareAstrology.com -
AnnouncementsComing Soon:
Fundamentals of Complete Crash and Hang Memory Dump Analysis
Management Bits: An Anthology from Reductionist Manager
Crash Dump Analysis for System Administrators and Support Engineers
New Magazines:
Debugged! MZ/PE: MagaZine for/from Practicing Engineers
New Books:
Introduction to Pattern-Driven Software Problem Solving
Memory Dump Analysis Anthology: Color Supplement for Volumes 4-5
Windows Debugging Notebook: Essential User Space WinDbg Commands
Memory Dump Analysis Anthology, Volume 5
Memory Dump Analysis Anthology, Volume 4
Memory Dump Analysis Anthology: Color Supplement for Volumes 1-3
Memory Dump Analysis Anthology, Volume 3
First Fault Software Problem Solving: A Guide for Engineers, Managers and Users
x64 Windows Debugging: Practical Foundations
Also available:
Windows Debugging: Practical Foundations
DLL List Landscape: The Art from Computer Memory Space
Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
