3

Please help me with this subject considering that I am not a programmer but more of a power user. Let's say that I would like to contribute to a source-closed application where I find diverse issues by utilizing procdump for example. Obviously, the list of potential issues is huge : hangs, crashes, memory corruption, etc. What is intriguing is that, as user, I find a lot of hangs that normally do not provide an every time replication (eg appear in certain conditions such as low memory, cpu, driver interference and other "bizarre behavior").

I usually use WinDbg + Microsoft Symbols Server and check FOLLOWUP_IP. However, I have noticed that some issues get the same bug tracking number from devs which means that it's a possible duplicate.

Thus, the question: As a user - How do you tell based on dump file only that you experienced a different issue than you reported in the past? Is my method bad? Any other methods?

Many thanks!

Marius Ilie
  • 31
  • 1

2 Answers2

2

In general, you can't.

If the dump file is identical to another dump file, you probably found the same problem. If they are different, you need to know enough about the application to know which dump file differences are relevant. The developer may have that knowledge because they have the source code. An experienced hacker may have enough general experience with how software works to figure it out. For everyone else, the dump file is worthless.

  • That is understandable. However, are there any tips? Is the method very inaccurate? – Marius Ilie Feb 06 '16 at 23:42
  • There are probably tips, but this is the wrong place to ask about them. I suggest finding a hacker forum. –  Mar 07 '16 at 19:12
0

If you are getting the same bug number for different dumps, try to see if there are any patterns in those dumps. Look for any similarities in the data, time of day, configuration (if it is available to you), etc. As others mentioned, it is best if you have some knowledge of the system and what it does, because that will help you see these patterns more easily.

In this case of black-box testing there really is no "magical" way to know what bugs generated what outcomes.

If you want to help developers be more efficient (and not mark so many bugs as duplicates - I am assuming that is the motivation for this question), try to give them more information on the system status and the actions you took to produce a certain outcome.

Maira Bay
  • 194
  • 3