Tiemo Hollmann wrote:
from time to time I have customers where my LC 4.6.4 program crashes on
windows machines right away when launching. The only error message is the
generic windows message "windows has encountered a problem".
I know that this can happen from everything. Installation without enough
permissions, missing or corrupted windows files, anti virus programs,
viruses, etc. In most cases I don't find the reason, beside saying "you
could reinstall your windows, etc." Though these cases are below 1% of all
my installations for the customer it is 100% of fault. And they tell me of
course that "all other programs run fine on their computer and just my
program is shit" What it makes worse is that often just these customers do
very hard to operate their computers or even don't have internet access, so
no chance to make remote diagnostics. Because of the 100% unsatisfying
experience for the customer it is also very frustrating for me, not being
able to help.
I am not experienced enough to see if this is a typical LC problem, or an
individual problem of my program (the only "specials" is using Valentina and
some shell calls) or is a LC program not worse or better as the average of
all windows programs?
How are your experiences and how do you approach these kind of errors / what
do you tell your customers?
Scott Raney used to include this in the MetaCard release notes:
MetaCard is very good at exposing bugs in the drivers for graphics
cards. These problems seem to be most frequent in Windows 98, but
can plague any Windows system. The most common symptom are images
or cursors that draw in the wrong colors or with the mask and data
reversed, and bits of windows left on the screen when they are
closed or moved. Be sure you have the latest drivers from the
vendor of your graphics card. If the problem still exists with
those, try turning acceleration to its lowest level. If that
doesn't fix the problem (or even if it does), please report this
bug to the vendor of your graphics card.
I love that opening line. :)
I used to think that was sheer arrogance. After all, if MC apps are the
only ones that crash, how it could it a system problem?
Oh, how I used to argue with Raney over this, but he'd patiently tell me
to please double-check the drivers and update as needed, and let him
know if the problem persisted after an update.
In most cases it never did.
So I'd start with that: make sure the video drivers are the very
latest from the manufacturer, and if the system in question has any
unusual devices attached to it (scanners, etc.) make sure those drivers
are current too.
Also check that any anti-virus software is up to date, and verify
whether it's truly the case that no other app has had other problems on
the machine (I sometimes find that frustrated customers may forget in
their initial report that they've had issues with other apps before).
If all that checks out it may be a problem with the engine, but
isolating it will take some work. In such cases I've sometimes found it
helpful to make a custom build with logging in it, so that the last item
logged will tell me where it crashed. That'll be essential for
diagnosing the issue with RunRev.
You could add logging handlers interspersed throughout your code, but
it's tedious and not always effective.
Simpler is to use a couple of undocumented things to get a very
comprehensive log of everything:
-- in your initialization stuff:
on StartLogging
insert script of btn "LoggerFS" into front
set the messageMessages to true
open file (specialFolderPath("desktop")&"/MyLog.txt") for append
end StartLogging
-- in the LoggerFS button used as a frontScript:
on messageHandled pType, pMessage
write the internet date && the params &cr to file \
(specialFolderPath("desktop")&"/MyLog.txt")
pass messageHandled
end messageHandled
-- somewhere in your quit stuff, if your program lives that long:
on StopLogging
close file ("specialFolderPath("desktop")&"/MyLog.txt")
end StopLogging
Here's what that does:
The messageMessages is a global property that's off by default, but when
set to true it generates "messageHandled" and "messageNotHandled"
messages for every system message, command, and function call used in
any script.
I've never found the "messageNotHandled" message useful since it's only
sent for messages that aren't handled in the message path, but
"messageHandled" can be invaluable for this sort of logging since it'll
tell you the name of pretty much everything that's called during script
execution.
WARNING: These logs can be big. Really big, since they record
literally everything, including every mouseMove.
It may be wise to filter out some messages less likely to be the
culprit, e.g.:
on messageHandled pType, pMessage
if pMessage is not among the items of \
"mouseMove,idle,mouseEnter,mouseLeave,mouseWithin" then
write the internet date && pType && pMessage &cr to file \
(specialFolderPath("desktop")&"/MyLog.txt")
end if
pass messageHandled
end messageHandled
If you want to see an example of the messageMessages at work check out
the 4W Flight Recorder tool. It's in the Stacks section of RevNet - in
the IDE see Development->Plugins->GoRevNet
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
