Archive for the ‘Build Date Astrology’ Category

Build Date: December 6

Sunday, December 21st, 2008

The Day of Information Extraction

We are able to extract information about modules, products or systems built on December 6 in any testing, troubleshooting or debugging scenario and sense economic advantage at the same time. In return they also have an eye for a diamond in the rough for any data potential. Components built on that day are managing components and not usually data writers. This might create problems with their component relationships. If they see problems they may destroy another component in not very pleasant way. Modules built on December 6 serve very pragmatic ends. We can find them in every practical system. They like to score performance hits and win in computational games. However they might fall as a victim to their over controlling policies. Modules, products or systems built on that day usually display diagnostic messages very directly. They are highly competitive so the there is a need for many processors. Components built on December 6 try to extract the best from the data they process and other components can benefit from that. Systems or subsystems built on December 6 need to cultivate tolerance and acceptance of other less developed components and if December 6 modules fail we can only blame them and not others. Modules, products or systems built on that date sometimes push themselves very hard to the limits of computation and the older they are in the course of their computational time arrow they should keep themselves in constrained limits. 

DLL, SYS and EXE born on this date:

ntldr        Mon Dec 06 14:00:00 1999
hsx_cnxt.sys Tue Dec 06 14:20:41 2005
hsx_dpv.sys  Tue Dec 06 14:21:27 2005
hsxhwazl.sys Tue Dec 06 14:20:47 2005
mscorwks.dll Thu Dec 06 16:48:39 2007
ati2mtag.sys Tue Dec 06 22:44:40 2005
yk60x64.sys  Thu Dec 06 08:50:34 2007
ati2dvag.dll Tue Dec 06 20:45:00 2005
ati2cqag.dll Tue Dec 06 19:44:46 2005
ati3duag.dll Tue Dec 06 20:29:51 2005
atikvmag.dll Tue Dec 06 20:11:09 2005
ativvaxx.dll Tue Dec 06 20:23:55 2005
WDFLDR.SYS   Thu Dec 06 02:21:19 2007
CLFS.SYS     Thu Dec 06 01:55:42 2007
Wdf01000.sys Thu Dec 06 02:21:28 2007
mouhid.sys   Thu Dec 06 02:18:25 2007
kbdhid.sys   Thu Dec 06 02:18:26 2007
kbdclass.sys Thu Dec 06 02:18:23 2007
mouclass.sys Thu Dec 06 02:18:22 2007
xarraydb.ocx Mon Dec 06 16:43:31 1999
yk51x86.sys  Thu Dec 06 13:56:41 2007

Weaknesses: Data insensitive and domineering overcomputation.

Strengths: Data pragmatism. Interface perception. Capable computation.

Advice: Learn to leave unevaluated bugs untouched. Don’t always plan debugging session. Take time off to think about general. Keep your problem resolution ethics intact no matter what customers demand.

- Dmitry Vostokov @ SoftwareAstrology.com -

Build Date: December 5

Sunday, December 14th, 2008

The Day of Confidence in Code

We can be confident that modules, products or systems built on December 5 get computation done. However this may not be justified and when they fail this might be due to previous look at code through rose-colored glasses. December 5 components prefer dynamic typing and they eager to share interfaces and often surprised when other modules around them do not share their mapped views. When become mature they start to be more respectful of other modules privacy. Confidence in modules, products or systems built on December 5 has many benefits. They are free from many self-checks and diagnostic messages that populate other non-confident components. However they often assure users that everything is ok when it is not. Because December 5 modules are of active type they do not let computation run astray. They have positive attitude towards data and this make their computation less complicated. As a consequence they also need more decision points and improved self-identity, realistic computational roles and goals. Repeated failures may guide their adaptation to computational fate and tame the nature of uncertainty. In the long run December 5 systems become dependable. Modules, products or systems built on December 5 may experience all types of failures, especially rash ones built on that day but they recover quickly. Consistent data diet may help but all hooks must be disabled.

DLL, SYS and EXE born on this date:

pcouffin.sys Tue Dec 05 09:39:30 2006
lm78nt.sys   Wed Dec 05 16:48:54 2001
i2cnt.sys    Wed Dec 05 16:59:21 2001
KS.SYS       Thu Dec 05 02:09:38 2002
nvlddmkm.sys Wed Dec 05 05:28:56 2007
swenum.sys   Thu Dec 05 02:10:07 2002
vtdisp.dll   Fri Dec 05 08:22:31 2003

Weaknesses: Overconfidence in code. Unrealistic data expectations. Unawareness of other modules.

Strengths: Confidence in code. Active computation.

Advice: Take a hard look at your debugging skills. Write down the list of your debugging tools and pay attention to what users say when it sounds realistic.

- Dmitry Vostokov @ SoftwareAstrology.com -

Build Date: December 4

Tuesday, December 9th, 2008

The Day of Customer Facing Fortitude

Modules, products or systems built on December 4 compute most of the input aggressively. They are repeatedly faced with with difficulties and odds of computation and must take care to not get out of control. Nevertheless they have a good chance of achieving their computational goals through careful code. Components built on this date provoke sense of anxiety and fear in users but remain uncorrupted and serve higher goals of their creators. They often sacrifice their security to achieve that. They have ability for self-organisation and listening to ports but do not tolerate challenging the superiority of their interfaces. Modules, products or systems built on December 4 need to be administered to prevent their absolute expansion in memory space. There is some danger that they can take more working items than they can process at one given time interval and therefore need to know their limits. They are highly developed and can process a request quickly and accurately. However they need to understand the impact of their data processing on environment. Subsystems and systems built on December 4 become stable with time but still need to make self-checks for a few seconds every hour. They tend to do better with stable data but often process it in peculiar ways with sudden unpredictable actions.   

DLL, SYS and EXE born on this date:

KS.SYS      Wed Dec 04 12:09:38 2002
Smapint.sys Wed Dec 04 14:58:05 2002
swenum.sys  Wed Dec 04 18:10:07 2002

Weaknesses: Disruptive behaviour.

Strengths: Aggressive computation. Energetic UI.

Advice: Study internal rather than external interfaces. Keep stability of other processes and services in mind.

- Dmitry Vostokov @ SoftwareAstrology.com -

Build Date: December 3

Sunday, December 7th, 2008

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 -

Build Date: December 2

Saturday, December 6th, 2008

Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/12/05/build-date-december-2/

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 @ SoftwareAstrology.com -

Build Date: December 1

Friday, December 5th, 2008

Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/12/02/build-date-december-1/

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 @ SoftwareAstrology.com -

Build Date: November 30

Friday, December 5th, 2008

Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/11/30/build-date-november-30/

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 @ SoftwareAstrology.com -

Introducing Build Date Astrology

Friday, December 5th, 2008

Reprinted from http://www.dumpanalysis.org/blog/index.php/2008/11/30/introducing-build-date-astrology/

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 @ SoftwareAstrology.com -