A bug is a programming error, meaning, a programmer has to go back to the source code (and sometimes to the drawing board) and improve and/or fix the algorithm triggering the error. This is called debugging. There is nothing the end user can do about a bug. That is not her department, she can't possibly fix a bug. Wikipedia defines it like this: "A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." This is, by the way, a fascinating discipline (and art) and at the same time a source of big headaches for perplexed, baffled, puzzled developers. I've been there, myself. en.wikipedia.org/.../Software_bug. Regards,

Hi Ozzie,

I do know that, but we can't reprogram an end user's software when they are in trouble. We can only find a workaround, flush out the carburetor rather than changing the jets. Not a good analogy because changing the jets would be best if a mechanic already had the car bonnet/hood open but end customers can't reprogram their software.

This bug can occur in other software, not just Studio, so for example it could be a Windows error that Studio can't diagnose. So I guess what you are saying, actually, is that the message itself should be more explicit? Or you're saying the programmers should not have made the mistake in the first placed - this is impossible, even if the programmer makes NO mistakes as such, interaction with other software in different setups can trigger events that are unexpected. Or expected but not possible to prevent. The developers/programmers obviously must be trying to deal with as many of the bugs as possible but we the end users have to help each other cope with the results in the meantime.

If the error is only generated by something occurring outside of Studio, a Windows Update for example, then a Windows Repair might smooth that out. Like servicing a car, it is actually a good idea to run a Windows repair on complex software periodically. It's useful to repair Microsoft Office occasionally, too. 

It isn't always 'an exercise in futility following instructions like "reset", "reinstall", "reboot"' because sometimes it works. It does feel a bit silly repeating the list of possible solutions but they are just that, possible solutions. Quite often new users would even find those steps hard to perform so how does it help them to just tell them that 'Again, this is a programming error (a bug). Nothing else'? 

I send people two links, the first SDLs own help list of the above solutions whose the final step is to reinstall then if that does not work to contact SDL free licensing and installation help, the second a clearer explanation and link to that last step. All the first options might solve the problem thus save wasting SDL help's time but if not, then someone at SDL can look at the setup remotely and find a way to help. Or I send a shorter, clearer version if I think the help page will be too difficult for the user.

I don't do this to gain points, I do it if I think that nobody else with better knowledge than mine is available on the Community. It's a starting point and better than leaving a user alone not knowing what to do. I'm sorry if you think my actions are futile but I don't mind that, I understand.

Very best wishes,

Ali [:D]