On StackExchange, we close questions that are too broad:
There are either too many possible answers, or good answers would be
too long for this format. Please add details to narrow the answer set
or to isolate an issue that can be answered in a few paragraphs.
First: this doesn't mean they are bad questions, or that the people participating in the close vote are trying to be mean. I am genuinely interested in the cause of the bug you are describing, but it would be wrong of me (especially as a moderator) not to vote to close your question as it was asked.
Second: precisely what constitutes "too broad" varies somewhat between SE sites. SO's definition may be more lax than ours. Or it could simply be that nobody with sufficient voting privileges on SO's far more massive site saw the question in a reasonable timeframe. It's generally not a useful argument to point to another borderline-poor question and say "but this one is still open," because that usually just means you call attention to a question that should also be closed that just managed to slip through the cracks.
Third: the argument that a broad question should be acceptable because one of the many potential speculative answers might lead you to, or actually be, the correct answer doesn't hold on SE. That isn't the kind of question SE is dedicated to archiving (with the outlying exceptions of some of the "softer" sites like Programmers). On SE, we want to keep specific questions with specific answers; for everything else, there are forums. Your question isn't specific enough.
- You haven't provided much information. Potential answers that tightly bound the limited information you have provided are many, even if most of them are wrong.
- XNA itself does not have a commonly-report bug regarding the window "shaking" on Windows builds (there many reports of things shaking, but they are almost exclusively having to do with things like half-pixel offsets of window content, which don't fit your description thus far.
- One doesn't need to know anything about the specific issue to know that the reported issue is too broad. "Why does my game crash?" is too broad a question regardless of if I've ever seen your source code.
- A question that requires intensely project-specific knowledge (such as a bug known to an internal or former XNA developer) is too specific, relying on the assumption that such a rare beast will happen to stumble across the question. We do have a few people here who have worked on XNA, but this isn't a site to ask them questions specifically. Since we no longer have the "too localized" close reason, we actually tend to (amusingly) close these questions as "too broad" since they fall under the umbrella of "everybody else without the specific knowledge would have to speculate."
- Finally, a question with so little information could have a straightforward answer; for your question that might be "the window shakes because of bug #6182 in XNA," as you initially hypothesize. But for another user searching this site for "why does my XNA window shake?" the answer might be because they adjust the position of the window themselves, accidentally, somewhere in their render function. The lack of scoping information in your question makes it hard for that future user to disambiguate your problem from theirs (because they were very different problems even if they have similar symptoms). An important goal of SE is to collect questions and answers for posterity, not just to solve an individual users problems, and these sorts of questions are counter to that goal.
Speculation is for forums, not GDSE. It doesn't matter that a million monkeys speculating might eventually produce an answer that is, or leads you to, the solution. That's a great process (bouncing the problem off others), it's just not what this site is for.
I do happen to know a fair bit about XNA, enough to know that this issue you've described as you have described it is very unlikely to be a problem purely in XNA's code. Something about your code is causing (directly or indirectly) the behavior, which means some of your code (or a video of your bug) is going to be necessary to diagnose the problem. That starts to get into "debug my code" question territory, which is why it's probably better you hash out the problem in the [chat] first to get all the back-and-forth involved in those questions out of the way, and then edit your question with the clarified information from that discussion.
