New
#1
Can I offer a third suggestion, Bad Coding philosophy,
The modular way of programming is a good thing, generally, but bad use of this methodology can cause problems for the user when they see an issue, and the programmer has chosen to use a pre-built error routine to handle the exception - In this case they use the permissions error dialog to present to the user when the issue is a missing file. OK, there is no real problem with this, if you understand that it's a fudge solution, but a lot of less experienced users will be quickly drawn down the rabbit hole of hunting for permissions that are irrelevant if the file does not exist.
In the old days you would write a handling routine for every exception, the problem with this, especially in a "built by committee" software, is that there is less likelihood of an overall theme to the design. How it should be done in my opinion, is that the lead programmers have to write the library of all possible error handling routines at the start and this pool should be added to if a specific routine does not exist for the job.
Thanks, so it's one of those typical cases where the only thing tested (and designed for) is the normal case, not the exception. The exception being, presumably, that I don't have a network configured, and have tried to run the troubleshooter.
It's actually more that there are only a limited set of messages available to the assigned programmer and so they, rather than write a bespoke routine they select the closest from those available, this could be down to laziness, or company rules, that would mean a load of work to get a new routine approved.
In the good old days, the error message would be more like "Sorry I cannot troubleshoot a network that has not been configured, these may also be relevant ... ... " and a list of links would be appended to the message, to errors and configuration of networks
Thanks, I quite understand the process- I was in software development/electronics in telecomms for some years (and I was, as you say, particular about error messages on the test gear we developed!).
I am left wondering why clicking the troubleshooter failed, and whether others with no local network see exactly the same thing, or whether it's just a problem on my PC.
** if I try executing msdt.exe directly - d. click in either system32 or syswow64 I see
I'm guessing it's normally run with parameters...
It looks like it's only supposed to be run when he user is on the phone with a MS tech Support agent, which is the only legit reason why the prompt appears. There are some Malware that hides as this file, I doubt that that is the case with yourself , but it may be worthwhile checking to be sure - Fire it up to Virustotal or somewhere similar
msdt.exe Windows process - What is it?
That would be weird- for a built-in troubleshooter - but certainly makes sense of the dialogue - and even the first message. Virustotal =100% ok (System32 occurrence)
It would seem strange to have a troubleshooter you can't run without support- and if so, no indication that's needed in Settings. But hey, this is MS..
But again- does anyone else see exactly this (my first post)?