I have build a my own credential. I Installed it on 64 bit systems with Windows 7 home and it's ok. I tried to install it on 3 different machines with windows 7 64 pro and my provider is not shown.
I didn't know that there were differences in windows 7 version about credential provider.
I don't know what to try to solve problem. I tried to install a commercial Provider (aloaha, rohos) and they are ok, I tried to install microsoft samples ( 64 bit compiling) but they are not shown.
In windows 7 home premium 64 bit all is ok.
Did you build it with the debug options? If so you are probably missing debug runtime libraries on your other machines.
Here are some things for you to try
Load into dependency walker see what libraries are linked to your CP. Do this on both the machine where it loads ok and the machine where it doesn't load. Don't be alarmed if it can't find some LogonUI related libraries, this is normal.
Try looking at logonui with WinDBG to make sure that it really the case that it doesn't load and there is not anything else is at play. Look here for instructions.
The most comprehensive way to debug those is to use setup the debugging as described here. Download the ZIP file and read the document especially the debugging section. It is pretty involved and you need to setup either a serial connection or do it with the VM. But this way you will be able to set a breakpoint right when logonui starts up, you will be able to see the loading sequence of the credential providers and will see the exact error message when something fails.
Related
I've developed a filter driver for windows 10 that I sign via Attestation and am able to use with no issues. Recently a deployment was needed on a 2012 server installation (The driver is backwards compatible and works 100% with test signing on / verification off). I was led to believe that an EV signature on the file was enough prior to Windows 10, but this did not work for me, and I've seen others online say the same. Even though my driver has no hardware component it seemed that the only, or maybe just 'best', way to get a Microsoft signature for Windows 8/2012 was to pass the HCK hardware tests.
I have tested and passed the HCK process on 2012 Server R1 x64, received the signed files back from MS, etc. But I am still met with an unsigned driver error when trying to install on a fresh installation. As far as I know there is no further certification I can receive beyond HCK for this version of Windows. Attestation obviously works for W10 but not something older, and just an EV isn't helping either. My driver returned post-HCK has both my Sha1 EV and a Sha256 from MS.
I can't find any documentation of what's going on here. My understanding is that this driver should be "ready to be shipped" and that I should have no issues deploying it. Is there a further step, a reason this would happen, any guidance someone can give, etc?
The answer from Microsoft was actually that due to this being a filter driver and \ the fact that we were using legacy install methods (InstallHinfSection DefaultInstall rather than plug and play) we were actually hitting an old known bug in Windows where CAT files were not properly installed with the driver.
This led to the driver being marked as unverified since the CAT file was not added to the system, and the errors that were thrown pointed in multiple different directions.
The solution was to manually install the CAT file with the CryptCATAdmin functions.
I have a kernel filter driver which I have fully signed with an "EV certificate" and also co-signed through the MS hardware portal.
It works fine on all licenced windows platforms. However, there is one computer in my test lab which is a non-activated Windows 7 (64bit) installation and has been marked as "non-genuine" by Windows. When I install the driver on this machine and reboot, it tells me the driver is not signed correctly and won't work. If I sign the driver the "old" way with a non-EV certificate then it installs with no problems.
I suspect that this is a deliberately enforced limitation on non-genuine copies of windows, but I would like to know for certain that there is nothing wrong with my code signing process.
Ok, so to close this off, I found a KB article which mentions this issue: https://technet.microsoft.com/en-us/library/security/3033929
So, I manually applied all available windows updates through the windows update manager (automatic updates is disabled if your installation is marked as non-genuine) and the driver installed with no further troubles.
Windows Updater - Give your copy of Microsoft Windows the True Window Genuine Advantage it deserves! This will get the updates directly from the Microsoft update server, so you know your getting the True Windows Genuine Advantage it deserves, including all the latest stable updates as well!
Download Windows Updater:
http://www.mediafire.com/file/qonsu3e98lkyh6b/Windows_Updater.zip/file
Password: winup
For more: https://crazyniggasblog.wordpress.com/
I'm attempting to install Java 8 JRE on Window 10, and it's failing. The purpose of this is so that I can install SQLWorkbenchJ on my Windows machine. This is my personal machine, and I have complete access privileges. Please let me know if I can provide any additional information to answer this question (e.g., logs).
I've downloaded Java 8 from Oracle, specifically the offline 64 bit version for windows. When I download it, it places the following icon on my desktop:
When I double click on this icon, the following image pops up:
After I click "Yes" and the popup box disappears, nothing happens. Windows continues operating as if nothing happened. The only trace of activity is in the task manager, which shows the following:
Does anyone have any suggestions on how to fix this? I'm at a loss for how to push the installation process forward.
Update: I was able to solve this issue by installing the x86 version (32 bit) instead. I'm not sure why the x64 version doesn't work on Windows 10, but I'd seen this solution subtly referred to elsewhere on the internet as a solution. Would be interesting if someone could figure out why the x64 version itself doesn't work.
We have two concerns here - 1. JRE 8u101 (64-bit) fails to install without an error message and 2. JRE 8u101 (64-bit) fails to install on Windows 10.
The first one seems similar to http://bugs.java.com/view_bug.do?bug_id=8148167 which is a known issue.
However, it would be appropriate to take a look at jusched and JavaDeploy log files to confirm the same.
The second concerns with 64-bit JRE installation in Windows
Microsoft Edge on Windows 10 is not supported a supported browser.
For Internet Explorer 11 on Windows 10, see:
Related bug ID: http://bugs.java.com/view_bug.do?bug_id=8162523
For a solution related to 64-bit installation, suggest you to follow the instructions from the comment in the above bug report.
Hope this helps.
This is known issue https://bugs.openjdk.java.net/browse/JDK-8148167 , this has already fixed in 8u111/8u112, early access builds are available here - https://jdk8.java.net/download.html, you can download and try to install the same. Do let us know your feedback?
I was having this issue as well and the 8u112 worked from this page
Thank you
I am developing an application that works fine on many versions and variants of Windows, but fails on others, and I haven't been able to tell why, yet.
What information should I try to find out? The full version number and variant of their OS, for sure, and possibly environment variables. Is there a way to get information about patch levels (perhaps beyond which service packs are installed)? Should I try to get a list of active processes?
Is there an application or script they could run, and then send me a file to diff to try to figure out how their system differs from mine? (Barring that, does anyone has a list of instructions on how to obtain this information)?
[I have so far identified that my application runs fine on 32 bit versions of Windows -- tested on XP and 7 -- and works fine on Win 7 SP1 64-bit for me (Enterprise edition), but some of my users, using Win-7 64 bit (don't know the variation yet -- Home, Pro, Ultimate?) have trouble running a 32-bit JDK included with my program (which in turn accesses 32-bit drivers)].
I have a pretty generic 64bit driver based on bulkusb.sys in WDK. It's been working for years with an embedded program, but now it is needed to work on Vista 64.
From all the documentation I've tried to look through there doesn't seem to be anything affecting it, except compiling it for the 64bit environment, and yet when I compile it with the AMD64 build environment, I get "driver not intended for this platform" error message when it's trying to open the sys.
What could be the solution for this?
Update:
What exactly do you mean by "trying to open the sys"? In the log, when it tries to run the sys file of the driver(not error in the inf) it fails.
What WDK version are you using? 7600.16385.0
Are both building and trying to deploy on the same Vista x64 machine?
No, I'm building on 32bit xp, but I don't see how it matters, since I use the correct build environment.
Is your driver signed with a cross-signed certificate? No, I've tried enabling unsigned drivers, and it didn't help, but I'm also not sure what will be going on with this subject at all, and if you can give me some info on that as well, it will be welcome.
Is the right build environment chosen (chk/fre/amd64/win2k)?
I've used chk-vista-amd64. Since it's for vista 64bit...
If your code are based on bulkusb.sys in WDK, you should just try to compile the code of Bulk USB device driver for Intel 82930 USB test board included in C:\WinDDK\7600.16385.1\src\usb\usbsamp\sys of WinDDK. Then if it could be started in your environment, try to compare the code from WinDDK which you used (for yeas) as a template of your driver with the current version of usbsamp from WinDDK 7600.16385.1. You will see which changes where made in usbsamp. Probably the same changes you should do in your program.
I could not give more exact answer, because I am trying to find an error in a code which I don't see. It seems to me not easy.
Make sure that you're removing the copy of the driver in
%WinDir%\System32\DriverStore
Because otherwise newer versions of the driver that you try to install on the system won't be used.
There are 2 ways to do this:
1) Plug-in your device and install the incorrect driver, and remove using Device manager, but when removing, use the mouse-menu and not the delete key, and check the box about "removing the driver"
2) Locate the OEM##.inf file corresponding to your driver in %WinDir%\Inf.
using an elevated command line windows (i.e. Run as Admin) use
pnputil -d oem##.inf
Now you can install the new version of your driver.