We have the "insufficient info to troubleshoot" close reason:

Questions seeking installation, configuration or diagnostic help must include the desired end state, the specific problem or error, sufficient information about the configuration and environment to reproduce it, and attempted solutions. Questions without a clear problem statement are not useful to other readers and are unlikely to get good answers.

But does this apply to questions where it's essentially impossible to troubleshoot the problem, no matter how much information the OP provides? This is maybe not the best example, but it's the question that made me ask:

Application does not run for domain admins

I've dealt with applications like this (FedEx and UPS, for example) and they're a nightmare to get right.

I voted to close as "Too Broad" because, as I said, I think it's usually impossible to do this remotely. But is that the best reason? Or should this type of question be closed at all?

3 Answers 3


Personally, I'd tend to favor leaving them open. We may not be able to offer better advice than general how-to-troubleshoot-crappy-code instructions in order to give it the permissions it requires, but this is a useful skill to have, and one I've ended up using with depressing regularity. I'm pretty sure that every job I've had in my career thus far has involved doing this with at least one app, and one job not too long ago, I had to do this for a handful of Windows apps, a couple unix apps and one mainframe app.

This whole problem is certainly nothing that's going away any time soon, so having answers to these questions, even with just generic answers, strikes me as something that provides a fair amount of value.


What HopelessN00b said. I've supported some truly horrible applications. Not horrible from the end-user standpoint--they did the task the end-user needed them to do, sometimes quite well--horrible in the sense that they were poorly coded to need more privileges than they should, or horrible in the sense that they had horrible, poorly-built installers. We were stuck with them because it was a niche application.

In particular, some disability support software does not work and play well with others, and/or has some bizarre and obnoxious licensing method. When I worked at a college, we were legally required to provide access to students with disabilities. Also, things that you would look at and think, "Yeah, they have a small market share," also tend to have twitchy installers and weird permissions--like software to manage student logins in a college computer lab. At one point, our print management software would cause a the client to boot into a BSOD until you booted into safe mode and applied a patch--this was a stated, known, normal part of the install. And don't get me started on the server install of the same product where the server BSODing was a normal part of the install, depending on your OS.

So no, we don't support [insert name of niche application here], but we do support "my business requires this horrible crappy software; how do I get this crappy code to actually function in my environment?"

IMHO, of course.

  • 4
    P.S. I didn't manually boot 2000 lab computers into safe mode to apply a patch. I added the horrible BSOD-inducing driver and its patch in the lab's already thick image and reimaged the lab. Commented May 7, 2016 at 13:04

For me it's too broad.

As for me such question fall into the answer to use processmonitor if you can't contact the software vendor.

Does we support application not supported by the vendor/coder, I don't think.

The OP told that the vendor just can't find the problem, then the vendor got a bad coder, as that mean that app is badly coded and they doesn't even know why it need admin right. Helping the OP to get a processmonitor's dump will someday give a result, that is maybe bypassable or that would give enough information for the OP to escalate to the vendor, but it's for me a break and fix, not an actual fix for the problem as we do the vendor's work there.

I give an actual case I lived. I escaladed a bug on a windows software, citrix desktop delivery agent in my case. The vendor asked me a processmonitor on boot, sent it via ftp, he readed it and offered me a fix. This is how it should work in my opinion.

Edited : My opinion told is based on the fact that the OP already got an answer from the vendor. Not like hes left in the wild without answer.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .