Hi,
The coinstaller has been a real pain for me. I first had problems with it due to check/free mismatch issues. Seems the files were swapped in the WDF files so the checked version was in the free folder and vice versa. That fixed that problem. But now I’m having the same issue again on a different computer.
My driver installed and runs just fine on a Core Duo laptop. On the Core 2 Duo desktop, I’m getting the mismatch error again. Any ideas?
Thanks,
Daniel.
We have never released either coinstaller (UMDF or KMDF) with checked and free versions reversed, to the best of my knowledge (and just to be sure, I also asked some of my colleagues). We specifically test for this situation prior to release.
I suspect you may be misunderstanding their purpose (because it is a common error to make). The checked coinstaller is needed on checked OS builds (no matter which build of driver [checked or free] you are installing).
Unless you have checked OS installed on these machines, you should be using the retail version of the coinstaller. It supports drivers built as checked or free.
If you believe you have a package with these reversed, please let us know which package it is and where it came from.
Well actually, when I downloaded the WDF files from Microsoft, I compiled at first using the checked version. I then went to the redist folder and copied the co-installer in the checked folder and I kept getting mismatch errors. I decided to try copying the one from the free folder and used that and it worked. I then compiled using the free compiler, and tried the checked folder for the co-installer and that worked as well.
Any way, I recompiled my files again on the new machine I have and tried installing and now my driver works. The problem is that my coworker still is getting mismatch errors with the same files I’m using. And yes, it’s the free version of the driver and what worked before for the co-installer.
Just tried reinstalling the driver on the Core Duo laptop with the co-installer from the free folder and it worked. The interesting part is that it was running before with the co-installer from the checked folder.
Daniel.
Once you have the framework installed, running with the incorrect version of the coinstaller is a no-op (because the correct version is already installed), so the fact that you have a mismatch at that point didn’t matter. Both times it “worked” when you used the correct one (free version) and after that all you wound up with was getting a pass on using the wrong one because the framework was already installed.
Use the free version of the coinstaller unless you are installing on a checked build of the OS.
Painstakingly blow-by-blow:
>
Well actually, when I downloaded the WDF files from Microsoft, I compiled at first using the checked version. I then went to the redist folder and copied the co-installer in the checked folder and I kept getting mismatch errors.
<<
The update package in the checked version of the coinstaller looked to see if it was installing on a checked OS, and it wasn’t, so you got the mismatch errors reported, because you were using the wrong coinstaller for the OS type you were installing on.
>
I decided to try copying the one from the free folder and used that and it worked.
<<
This was the correct coinstaller to use, because you were installing on a retail (non-checked)version of the OS. So it worked.
>
I then compiled using the free compiler, and tried the checked folder for the co-installer and that worked as well.
<<
It “worked” because the framework was installed by your previous usage, so the installation process didn’t even attempt to run the update package. In other words, since there was no need to install the framework, the mismatch didn’t matter. If you look at the coinstaller on these machines (in %windir%\system32), I’m pretty sure you will see it is the “free” coinstaller. The setup logs will also show none of the update activity when you used the checked coinstaller successfully because it never happened.
If you had completely uninstalled the framework between these tests, then this installation would have failed, as well. The checked coinstaller will not install the framework on anything other than a checked build of the kernel.
I assume the remaining portions are now clear as to what happened.
xxxxx@biometricsolutions.com wrote:
Well actually, when I downloaded the WDF files from Microsoft, I compiled at first using the checked version. I then went to the redist folder and copied the co-installer in the checked folder and I kept getting mismatch errors. I decided to try copying the one from the free folder and used that and it worked. I then compiled using the free compiler, and tried the checked folder for the co-installer and that worked as well.
Any way, I recompiled my files again on the new machine I have and tried installing and now my driver works. The problem is that my coworker still is getting mismatch errors with the same files I’m using. And yes, it’s the free version of the driver and what worked before for the co-installer.
Just tried reinstalling the driver on the Core Duo laptop with the co-installer from the free folder and it worked. The interesting part is that it was running before with the co-installer from the checked folder.
How are you testing this? Remember that the co-installer is only used
at installation time, when your driver has not previously been
installed. Once your driver is installed, the co-installer is no longer
used. You could copy the AMD64 version and it would still work. The
only way to test this to uninstall and reinstall.
The checked co-installer will not work on a free operating system. That
much is fact, and I think almost all of us can testify to that from
personal experience.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Odd because I got it to work with the checked version. At first I had
to use the checked version for the free build of the driver, and the
free version for the checked driver. This morning I was trying to
install the driver using both co-installers and it failed both times.
It didn’t work until I rebuilt and used the checked version.
Daniel.
Tim Roberts wrote:
xxxxx@biometricsolutions.com wrote:
> Well actually, when I downloaded the WDF files from Microsoft, I compiled at first using the checked version. I then went to the redist folder and copied the co-installer in the checked folder and I kept getting mismatch errors. I decided to try copying the one from the free folder and used that and it worked. I then compiled using the free compiler, and tried the checked folder for the co-installer and that worked as well.
>
> Any way, I recompiled my files again on the new machine I have and tried installing and now my driver works. The problem is that my coworker still is getting mismatch errors with the same files I’m using. And yes, it’s the free version of the driver and what worked before for the co-installer.
>
> Just tried reinstalling the driver on the Core Duo laptop with the co-installer from the free folder and it worked. The interesting part is that it was running before with the co-installer from the checked folder.
>How are you testing this? Remember that the co-installer is only used
at installation time, when your driver has not previously been
installed. Once your driver is installed, the co-installer is no longer
used. You could copy the AMD64 version and it would still work. The
only way to test this to uninstall and reinstall.The checked co-installer will not work on a free operating system. That
much is fact, and I think almost all of us can testify to that from
personal experience.
> The checked co-installer will not work on a free operating system. That
much is fact, and I think almost all of us can testify to that from
personal experience.
Well so far that’s been bogus for me as I installed the driver on a
clean machine. I just recently got this machine and hadn’t bothered to
install my driver on it as I was running it on two other test systems.
Like I said in a previous message, I tried installing it using both and
it failed. I rebuilt the machine as well as the driver, then used the
checked co-installer and that worked. After that, both versions worked.
Now if anyone can explain that it would be great. It would certainly
help not having to deal with mismatch errors anymore rather than having
to try both versions of the co-installer to see which one makes it happy.
If you wish to sort this out, then please try the following:
(1) Rebuild your machine- or take a fresh one from anywhere.
(2) Delete %windir%\setupapi.* (pre-Vista) or %windir%\inf\setupapi.* (Vista)
(3) Connect a kernel debugger to the machine.
(4) Boot the machine, break into the debugger, and enter “vertarget”. Save the results to notepad.
(5) Hit “g” to let the machine continue.
(6) Install the driver with the “bad” coinstaller. Record the timestamp and file size of that coinstaller. Also note the approximate clock time you did this installation (so there’s no room for error in interpreting the setup logs).
(7) Do the same with the “good” one. Record the same info.
(8) Email me (or post, if you prefer, although the size might be prohibitive) the vertarget output, the coinstaller file info, approximate install times, and the contents of The setupapi files identified in (2) above [which will now contain only setup activity since they were deleted).
We may need to follow up by checking some registry keys, but it is certainly possible to explain anything that occurred here if all of the evidence is available.
Can I run this from the GUI debugger or do I have to run it from the
command line. I must admit I haven’t done the command line yet so I
don’t know how that works yet.
Thanks. Currently getting the stuff I need to reinstall Windows on the
laptop.
Bob Kjelgaard wrote:
If you wish to sort this out, then please try the following:
(1) Rebuild your machine- or take a fresh one from anywhere.
(2) Delete %windir%\setupapi.* (pre-Vista) or %windir%\inf\setupapi.* (Vista)
(3) Connect a kernel debugger to the machine.
(4) Boot the machine, break into the debugger, and enter “vertarget”. Save the results to notepad.
(5) Hit “g” to let the machine continue.
(6) Install the driver with the “bad” coinstaller. Record the timestamp and file size of that coinstaller. Also note the approximate clock time you did this installation (so there’s no room for error in interpreting the setup logs).
(7) Do the same with the “good” one. Record the same info.
(8) Email me (or post, if you prefer, although the size might be prohibitive) the vertarget output, the coinstaller file info, approximate install times, and the contents of The setupapi files identified in (2) above [which will now contain only setup activity since they were deleted).We may need to follow up by checking some registry keys, but it is certainly possible to explain anything that occurred here if all of the evidence is available.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
If you’re familiar with the kernel debugging setup, that’s what I was thinking- in that case:
As long as you have the cabling right, you can use WinDbg as the debugger (I generally do- I dislike command line stuff).
Start the debugger, go to “File”, select “Kernel Debug…”, fill in the property sheet to indicate connection stuff (COM port, 1394 channel, whatever you’re using).
BUT, you could also install the debugger package on the test machine, use WinDbg on Notepad (for instance), and enter the same command at the first break. It will identify the OS and build flavor (at least, it’s a starting point).
As a followup, there were some lessons here to be learned.
One thing that seemed to have been happening was rather subtle:
Begin by setting up your package with the “wrong” coinstaller (checked in this case). Attempt an install, and it fails. But file copy occurs first, so the coinstaller is already in its proper place.
Now swap in the right one, and try to install again. The “wrong” coinstaller is already in use when the attempt to overwrite it is made [I believe this is a different manifestation of the KMDF 1.1 coinstaller issue mentioned in the release notes, but I haven’t had time to verify that yet], so the “right” one sits in a temporary file, ready to replace it on the next reboot.
But the wrong coinstaller is still being used, the installation fails, and you are never asked to reboot. You can repeat this cycle until you either remove the “wrong” coinstaller from the machine manually or (more cruelly subtle) reboot when the “right” one is waiting to replace it. In the latter case, you will then be able to use the “wrong” coinstaller, but see your device install.
We focused on end-user scenarios in testing versioning, and not a lot on scenarios related to the checked coinstaller, since it is only for devs, assuming they were sophisticated enough to understand the issues on their own. But this one- I could easily see myself doing the exact same things, and coming to the exact same conclusions.
When I get time (a bit scarce these days), I will verify whether this also happens with 1.5 (I expect it to also be a problem with 1.0, as it stands), and whether the flagging workaround takes care of this. Logic tells me the answers are probably “No” and “Yes”.
There is no risk to consumers from this behavior [since they can never use the checked coinstaller, and it is not for redistribution], but it’s not something (IMO) that should have got past us. At the very least [again IMO] we should have provided better guidance on what to do if you do inadvertently use the wrong one.
This is yet another manifestation of the classic coinstaller dependency hell. It is the reason why I avoid coinstallers unless there is simply no other good way to accomplish what needs to be done.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-286590-
xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com
Sent: Sunday, May 13, 2007 1:17 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF coinstaller issuesAs a followup, there were some lessons here to be learned.
One thing that seemed to have been happening was rather subtle:
Begin by setting up your package with the “wrong” coinstaller (checked
in this case). Attempt an install, and it fails. But file copy occurs
first, so the coinstaller is already in its proper place.Now swap in the right one, and try to install again. The “wrong”
coinstaller is already in use when the attempt to overwrite it is made
[I believe this is a different manifestation of the KMDF 1.1 coinstaller issue mentioned in the release notes, but I haven’t had time to verify that yet], so the “right” one sits in a temporary file,
ready to replace it on the next reboot.But the wrong coinstaller is still being used, the installation fails,
and you are never asked to reboot. You can repeat this cycle until you
either remove the “wrong” coinstaller from the machine manually or
(more cruelly subtle) reboot when the “right” one is waiting to replace
it. In the latter case, you will then be able to use the “wrong”
coinstaller, but see your device install.We focused on end-user scenarios in testing versioning, and not a lot
on scenarios related to the checked coinstaller, since it is only for
devs, assuming they were sophisticated enough to understand the issues
on their own. But this one- I could easily see myself doing the exact
same things, and coming to the exact same conclusions.When I get time (a bit scarce these days), I will verify whether this
also happens with 1.5 (I expect it to also be a problem with 1.0, as it
stands), and whether the flagging workaround takes care of this. Logic
tells me the answers are probably “No” and “Yes”.There is no risk to consumers from this behavior [since they can never
use the checked coinstaller, and it is not for redistribution], but
it’s not something (IMO) that should have got past us. At the very
least [again IMO] we should have provided better guidance on what to do
if you do inadvertently use the wrong one.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer