Forum Discussion
Is this the right place to raise bugs? Even doc/help bugs?
Is this forum the right place to raise bugs observed in the Sysinternals tools, even doc/help bugs? I'm asking because I had raised one here 3 weeks ago, but there's been no reply or action indicated.
I didn't think to prefix the subject with "BUG:", if that may be expected. And sadly the system here doesn't seem to let me edit a post once made.
I'm also opting not to ask this as a comment on that post: even a simple "ping" would seemingly cause it to no longer appear in the "no replies yet" list--in case that's how some here keep an eye on things. :-)
Is the bug critical? No. And since it's literally about the help ui, that may drop its priority still more--as it's not about functionality of the tool itself. But again is this even the right place to have pointed out the opportunity for improvement?
2 Replies
To be clear, the problem is in help text as offered IN THE TOOL, not in some MS Learn page. And the original post (linked to above) DID include the product name, version, repro step, expected and actual results--easily reproduced by anyone who would feel responsible for the tool (RamMap). I had indicated also that I had TRIED to offer a screenshot but it was not accepted.
Your concluding remarks seem to indicate that someone trying to report a bug by this means should have no expectation that anyone will acknowledge it, let alone consider it. There's the key answer to my question here. Sad, if true, but now I/we know.
Just trying to help. I'll leave it be and hope someday the issue may be addressed.
This forum is suitable for discussing Sysinternals problems, but it is not an engineering issue tracker and it has no response-time commitment. A “BUG:” prefix may help, but it is not a documented requirement. For a documentation or Help-text error, open the exact Microsoft Learn page and use its Feedback control; if that page offers the open-source experience, create the prepopulated documentation issue there. For a tool-functionality defect, keep the original forum post and add the tool name and version, Windows build, minimal reproduction, expected and actual results, and sanitized output or screenshots. Add a comment only when you have new evidence, not merely to change its visibility. If the problem affects production and needs tracked ownership, open a Microsoft support case and reference the forum thread. No reply means only that nobody responded publicly; it does not confirm that engineering accepted, rejected, or saw the report.
