Microsoft, what a bunch of tossers.
-
We are, but they haven't come up with an answer yet. MSFT have the source code though. They should know under what situations their PnP manager fails in this way. They should be able to tell us.
Munchies_Matt wrote:
They should know under what situations their PnP manager fails in this way. They should be able to tell us.
If they took the time to go back through and read all the source code. Get out your wallet if you want them to do that. If someone asked you to explain to them all conditions that could cause a certain issue in code you wrote 10 years ago, would you be able to answer?
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Munchies_Matt wrote:
They should know under what situations their PnP manager fails in this way. They should be able to tell us.
If they took the time to go back through and read all the source code. Get out your wallet if you want them to do that. If someone asked you to explain to them all conditions that could cause a certain issue in code you wrote 10 years ago, would you be able to answer?
There are only 10 types of people in the world, those who understand binary and those who don't.
Do you know what the word 'suppress' means?
-
Do you know what the word 'suppress' means?
-
Do you know what the word 'suppress' means?
are you sure it supresses the dialog or does a failure in the system stop the code that opens the dialog from running?
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
Munchies_Matt wrote:
Do you know what the word 'suppress' means?
Is that similar to "deflection?" :-\
There are only 10 types of people in the world, those who understand binary and those who don't.
:zzz: :zzz: :zzz:
-
are you sure it supresses the dialog or does a failure in the system stop the code that opens the dialog from running?
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
The error from the PnPManager, in event log, saying 'xxx failed because all user interface dialogs have been suppressed' gives it away for me. :)
-
:zzz: :zzz: :zzz:
Munchies_Matt wrote:
:zzz: :zzz: :zzz:
I see. That explains it. You expect Microsoft to know the ins and outs of their millions of lines of codes even though the person that wrote it isn't even there anymore yet you wouldn't hold yourself to those same standards. At least you're honest about it.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
Munchies_Matt wrote:
:zzz: :zzz: :zzz:
I see. That explains it. You expect Microsoft to know the ins and outs of their millions of lines of codes even though the person that wrote it isn't even there anymore yet you wouldn't hold yourself to those same standards. At least you're honest about it.
There are only 10 types of people in the world, those who understand binary and those who don't.
Its an explicitly logged error from the PnP manager saying that UI dialogs have been supressed. Do you understand what the term 'supress' means and do you think its the result of an accidental code error or an explicit setting?
-
Its an explicitly logged error from the PnP manager saying that UI dialogs have been supressed. Do you understand what the term 'supress' means and do you think its the result of an accidental code error or an explicit setting?
Munchies_Matt wrote:
Do you understand what the term 'supress' means
Yes.
Munchies_Matt wrote:
do you think its the result of an accidental code error or an explicit setting?
Could be either. I didn't write the code. Regardless, when you contact Microsoft you aren't contacting the developer who is writing the code. Trying to get access to a developer is like trying to get you to admit that global warming is real.
There are only 10 types of people in the world, those who understand binary and those who don't.
-
The error from the PnPManager, in event log, saying 'xxx failed because all user interface dialogs have been suppressed' gives it away for me. :)
if that message continues and mentioned factory then the fault could be in the installation of your OS I have this when its done using sysprep and not resealed, I have also seen this when the drivers have been built for un-attended installation and yet have a decision dialog in them - strangely this throws the same error so it looks like it propagates up and hits MS's error logging instead of reporting it itself
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
Munchies_Matt wrote:
Do you understand what the term 'supress' means
Yes.
Munchies_Matt wrote:
do you think its the result of an accidental code error or an explicit setting?
Could be either. I didn't write the code. Regardless, when you contact Microsoft you aren't contacting the developer who is writing the code. Trying to get access to a developer is like trying to get you to admit that global warming is real.
There are only 10 types of people in the world, those who understand binary and those who don't.
No, it is unlikely to be either, it is an explicit failure because of a setting somewhere. If MSFT don't know this then who the fuck does? Me? I didn't write their OS, they did.
-
if that message continues and mentioned factory then the fault could be in the installation of your OS I have this when its done using sysprep and not resealed, I have also seen this when the drivers have been built for un-attended installation and yet have a decision dialog in them - strangely this throws the same error so it looks like it propagates up and hits MS's error logging instead of reporting it itself
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
Bergholt Stuttley Johnson wrote:
the installation of your OS
Not mine, NCRs....
Bergholt Stuttley Johnson wrote:
have this when its done using sysprep and not resealed
Yes, its a similar error, except it doesn't say 'factory mode' None of the other known registry settings seem to be causing it either. And sop far NCR haven't found it.
Bergholt Stuttley Johnson wrote:
drivers have been built for un-attended installation and yet have a decision dialog in them
Our drivers ship with a co-installer, that doesn't have any UI in it, it only reads and writes some registry values. If this coinstaller is left out, the driver installs OK. So clearly the very existence of a coinstaller is enough to cause the system to fall over. Its really quite crap.
-
No, it is unlikely to be either, it is an explicit failure because of a setting somewhere. If MSFT don't know this then who the fuck does? Me? I didn't write their OS, they did.
-
So I raise a support question, "which registry values are causing component xxx to trace this error message in the event log, and fail the install of our drivers" "Ask NCR" was the response.
You should know better. Use Linux where everything is throughly documented. :rolleyes:
-
Bergholt Stuttley Johnson wrote:
the installation of your OS
Not mine, NCRs....
Bergholt Stuttley Johnson wrote:
have this when its done using sysprep and not resealed
Yes, its a similar error, except it doesn't say 'factory mode' None of the other known registry settings seem to be causing it either. And sop far NCR haven't found it.
Bergholt Stuttley Johnson wrote:
drivers have been built for un-attended installation and yet have a decision dialog in them
Our drivers ship with a co-installer, that doesn't have any UI in it, it only reads and writes some registry values. If this coinstaller is left out, the driver installs OK. So clearly the very existence of a coinstaller is enough to cause the system to fall over. Its really quite crap.
sounds to me like its a red herring, my guess is that something is going titsup and not being caught and bounces up the stack until its caught by the catch with that error I had this when it turned out the installation couldn't cope with a certain piece of hardware (in that case it was a USB controller that had been changed on later motherboards that wasn't mentioned in the spec) completely MS fault they should prevent any hardware changes as Apple does but that was just that time so don't think I am saying that's the cause in your case
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
Munchies_Matt wrote:
If MSFT don't know this then who the f*** does?
I'm sure they don't have every single little feature documented.
There are only 10 types of people in the world, those who understand binary and those who don't.
and they don't release all the documentation for the bits they do have documented
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
So I raise a support question, "which registry values are causing component xxx to trace this error message in the event log, and fail the install of our drivers" "Ask NCR" was the response.
You are the tosser. You should use Linux where everything is throughly documented. :rolleyes:
-
sounds to me like its a red herring, my guess is that something is going titsup and not being caught and bounces up the stack until its caught by the catch with that error I had this when it turned out the installation couldn't cope with a certain piece of hardware (in that case it was a USB controller that had been changed on later motherboards that wasn't mentioned in the spec) completely MS fault they should prevent any hardware changes as Apple does but that was just that time so don't think I am saying that's the cause in your case
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
Could be, but the big clue is that when the coinstaller is not on the system, it installs OK, so its as iff the existence of a coinstaller is automatically seen as a UI component and blocked. Of course the driver itself could read and write the registry settings, its trivial enough, but the 1st rule of kernel coding is put as much in user mode as you can because its cheaper, so that's where I put it. Of course the client could just run 'devcon upgrade nnn.inf VID_xxx' every thime it fucks up, but its not very user friendly. (Or the app could do it if the COM port wasn't there). Anyway, best if NCR find out what it is, their is the only machine this happens on, after 10 plus years of general usage.
-
You are the tosser. You should use Linux where everything is throughly documented. :rolleyes:
Yeah, it reminds me why I switched to Linux kernel programming, you really can do anything you like. Windows is such a black box, and MSFT such a crap company to deal with.
-
Yeah, it reminds me why I switched to Linux kernel programming, you really can do anything you like. Windows is such a black box, and MSFT such a crap company to deal with.
Munchies_Matt wrote:
Yeah, it reminds me why I switched to Linux kernel programming, you really can do anything you like.
Then why do you use MSFT?
Munchies_Matt wrote:
Windows is such a black box, and MSFT such a crap company to deal with.
I must ask again why do you use MSFT? X|