Re: Dialog: Flush Before Exit?

On Tue, 3 Jan 2012 14:11:15 -0600, Sqwertz wrote:

You need to *analyze* the interaction
between 40tude Dialog and your system to identify the cause(s) of
your problems. And to do so, you probably need to start from a
*clean* *parallel* Dialog installation. But /that/ I *already* told
you several times... :-(
You suggested that once and I found it a ridiculous exercise in
[Several examples snipped]
They all refer to the same thread. The same instance that you are
suggesting the parallel installation.

Nothing in my above statement refers to some obscure year old threads.
I was (and still am) talking about you lap-dancing around your current
problems, avoiding any personal effort.

I have no desire to go through all through all all my customizations
and options and add them back in one by one to find out where the bug
is. To do so would take well over a year and be inconclusive.

Purposeful iteration is the key. *Of course* you don't change the
foreground color for read messages and wait a couple of weeks,
whether this might have an effect on database write! :-(

A test plan with minimal input required would look like:
- clean new installation (outside a managed folder!)
- save new settings.ini and replace with old one
- restore new settings.ini and replace Data folder with old one
- keep old Data and additionally replace settings.ini by old one
- replace filters.dat (= Scoring/Actions) by old one
- import all Scripts, which you think can /not/ be the cause of the
crashes (don't forget helper files, if those scripts need them)
- add all remaining scripts

Once you encounter a crash, all remaining test steps can be omitted.
Instead, it may be prudent to dissect the step, which triggered the
crash, in more detail. This way, you should be able to identify the
culprit. If even the last step does not result in crashes, refine
the new installation to be used as the default one from this day on.

/Managing/ above steps should take less then an hour *altogether*.
More time consuming will be /working/ with every single setup. But
from step 3 onwards you can (at least) do a great deal of reading
over there.

As I said, the crash only happens randomly and can go weeks without
appearing. I would never know what causes it since I can't duplicate
it on demand. How would ever know if introducing back in a script or
option does or does not cause or fix the problem? I would have to
wait virtually indefinitely between each change.

Not really. As you can see above, you'd do changes in clusters.
With refinement only when it is necessary. Defining a sensible
waiting time is basic statistics. Increasing it too much may
increase confidence level, but with quickly diminishing returns.
If you chose the time span to short, you can always trace back.
Therefore, choosing a comparatively short time span between each
step (at most a week, for instance) can be combined with going
a whole step backwards with prolonged waiting time before doing
refinement search. E.g.: If putting in scripts triggers a crash,
you go back to no script at all and wait a good deal of time
before inserting some of the scripts back.

You could even do the whole process backwards: Fresh installation,
take all settings, Data, Scoring/Actions, Scripts from your current
installation. If a crash happens, you perform above scenario
backwards. This way you could even use the new installation for
daily work from the beginning. Only if crashes happen, you may
need to switch back to your old (= current) one.

I will post my next exception.


I do not use any active antivirus software, but I do scan every
once in while with MSE.

Are you sure that you explicitly disabled the real-time protection
of MSE? (It is on by default; and turning it off requires additional
steps to disable core Win7 AV policy warnings, as well...)

I check my system/application logs more regularly and have not seen
anything terribly suspicious (except unannounced write errors to my
thumb drives)

If one would search for a link between write errors on USB drives
and occasional disk access locks on hard disks (which is purely
speculative at the moment), a wrong/buggy chipset driver would be
a good starting point.