Fixed or Not Repro

Recently I opened a discussion on the Microsoft responses to issues posted in the PFC. One question we’ve been grappling with that’s related is how to resolve bugs that repro on the original build the customer reported the issue for, but on our latest internal builds, it doesn’t repro anymore.


Should bugs that don’t repro on new builds be resolved as “Fixed” or “Not Repro”?


The reason the bug no longer repros may be because the developer noticed it an fixed it without logging the bug (hence we wouldn’t have a duplicate) or the bug could have been caused by a build integration issue that has since been resolved.


I’m inclined to resolve the issue as Fixed since it does repro on the original build and seems to have been somehow fixed in the meanwhile, even if we can’t necessarily pinpoint the fix. What are your thoughts?



Marie Hagman

Visual Studio

Program Manager

Comments (15)
  1. Michael says:

    You shouldn’t resolve as fixed if you can’t pinpoint an actual fix that was checked in. For all you know, the bug may still exist, but be masked by some other behavior now, or may still repro but not as frequently on more recent builds.

  2. who cares says:

    Don’t even bother fixing it. Your customers don’t know any better.

  3. Bruce Morgan says:

    Michael is exactly right. If you can’t directly identify the change the fixed the bug, then it’s become a no repro.

    When your test team does a regression testing pass, they should treat "no repro" bugs with more suspicion than "fixed".

  4. It isn’t fixed unless you know what you did to fix it. I’d mark it "no repro" and as Bruce says, those bugs need to be looked at VERY hard by the QA folks.

  5. AT says:

    I feel that "Fixed" vs. "Non repro" is some kind of warranty that bug will not be appear in next build.

    "Fixed" will mean that this is definitely not going to reappear or very-very high probablity that it will not.

    "Non repro" will mean that bug likely not happend in next builds. But nobody can be sure about this and does not give any warrants (as this can be some kind of specific user-configuration).

    "Working on solution" / "Reproduced" will mean that bug will most-likey appear in next build. But has some probability to disappear.

    "Postponed" mean that bug will has a long life in next several builds.

    "By Design" this will mean that all future versions of product will have this tradeoff in code.

    😉 Simply my personal interpretation of thouse resolutions.

    As for my suggestion – if your bug were closed with "Fixed" / "Non repro" – try to reproduce it in next build (on clean PC, not a upgrade !!) and reopen/add comments to it if it’s still present.

  6. Marie Hagman - MSFT says:

    Thanks for the input and I like the definitions from AT.

    How about this:

    – if the person resolving the bug in question knows for a fact the specific problem was in fact fixed, resolve as "fixed".

    – if the bug does not repro on the latest build for an unknown reason, resolve as "not repro"

    Some people argue that customers want to see their bugs fixed so if it in effect is (ie no longer occurs) then "fixed" is a more amicable resolution then "not repro". Based on the feedback it seems you would prefer the most precise resolution.

  7. Knight says:

    I like AT’s idea.

    Although what i’ve seen through posting in the PFC that resolved bug, or added suggestion don’t seem to take into account, older suggestions, or bugs that were resolved as won’t fixed. Since from my experience, different teams take different bugs they might not be aware of newer solutions that might eliminate a ceratin old bug, or give newer functionalities. My 2 cents. 😉

  8. Knight says:

    Here i drop you a bug, that might have not been understanded by the team. And the resolution doesn’t take into account new feature that has been fixed. ([DesignerSerializationVisibility(DesignerSerializationVisibility.Content)])

  9. Joku says:

    If it doesn’t repro in latest build, always say it if it’s going be tagged as "doesnt repro". Then the user who submitted it has the responsibility of leeching the next public build and checking whether its fixed for real or not.

  10. Joku says:

    It would also help if the PFC was a bit more flexible:

    User A opens bug.

    The Bug is closed at date X.

    User B has a newer build (from date X+Y) and noticed the bug is still there, what to do? He can’t re-open this as the owner of the bug is someone else.

    There should be a system that allows re-opening by other users atleast if they have newer build and that the comments by other users would also be very visible to the MS people even if they do not bother going to PFC. If I understand correctly only the bug’s submitters notes are visible internally?

  11. AT says:


    Post comments in reports. Some users with elevated privileges can open / comment out any report – not only original submitter.

    Unfortunately – due to possible abuse (as comments will be replicated go to main MSFT database) it’s not allowed for everybody to change status of somebody other report for regular users.

    I hope in future – number of users with elevated (increased) privileges on PF will increase.

  12. Knight says:

    It would be cool if a checkbox could be added so that the user can say if he thinks the resolution is valid or not, before closing the bug / suggestion. And if after a week has passed since resolution and no Invalid resolution, then you automatically close the bug / suggestion.

    What do you think of this?

  13. Knight says:

    Just in case, if anyone needs to contact me.

    (First time posting around this stuff.) My e-mail.

  14. Marie Hagman - MSFT says:

    Knight – we’ve been discussing a feature just like the one you described. We would really like to know what customers think about the resolutions and responses MS gives to bugs. An "escalation" button for customers to be able to say "hey, I’m not happy with this, I want to escalate the issue" is one idea. What do you think of this?

  15. Knight says:

    Sounds great, since this weekend some of my posting have also became closed, some without a satisfactory answer. I would come in real handy, especially since Beta 2 should be coming along soon.

Comments are closed.

Skip to main content