In this thread i’m going to explain some useful tips and insights on how to properly craft a bug report in order to make life easy for the developers. first of all, if we take a look at an example, this isn’t a well made bug report. it’s missing extended details, even the core information that explains the cause, steps taken and expected output in order for the developers/QA team to reproduce.
so, let me start out by pointing out to a suite of useful tools that could make it possible to narrow down and hunt bugs quickly as possible. First, let’s use this thread as an example,
i think i found bug of some kind i suffered a random crash on windows 10
You think you found a bug? that’s great, if you “suffered” from a random crash then use AppCrashView to inspect the memory .dmp of the user-mode crash.
it was a blue screen those are rare now a days and stranger still it was IRQ NOT LESS THEN OR EQUAL haven’t seen that is a long time not since windows xp
oh, it was a blue screen? possible a kernel-mode crash caused by Comodo’s driver (was it the antivirus? the network filter driver? who knows), the status code of the error doesn’t give us enough information. Again, use the BlueScreenView to inspect the memory dump of the crash and upload the detailed .txt or a screenshot of the call stack.[1].
so i downloaded an app called " WhoCrashed " because windows event viewer is not usefull
that’s great, that piece of software has a call stack too, that should of been posted as well in order to narrow down the symptom. you see, we want to include as much information as we can in order to resolve bugs as quickly as possible.
my comodo version is " Comodo Internet Security Premium 12.2.2.8012 Database 38829 "
That’s great, build version of the product and database is excellent, this really helps narrow down things. But yet again, the call stack is the most important piece of information that could possibly resolve things fast.