Trying to turn on TPM on a computer with the TPM chip on windows 10 pro, version 10.0.19043, build 19043
Get a message to resolve any driver incompatibilities and scan again
I reviewed incompatible driver list
fei62x64.sys is the only one listed
It appears to be an intel network driver with creation date 10/1/2009
I have searched through stack for similar problems and they have not helped
I tried a program called dependency walker to see if it is in use and could not determine if it was
I added my userid and administrator explicitly with full control to the file
Looked at each of the entries for Intel under device manager driver details and the driver, fei62x64 is not mentioned
Decided to try to rename file
First did backup, fresh system image, and restore point
Unable to rename file
Added my personal user id and administrator as owners with full control
Still unable to rename file. The error I get is
ren : Access to the path is denied.
At line:1 char:1
ren fei62x64.sys fei62x64.old
+ CategoryInfo : PermissionDenied: (C:\windows\syst...c1\fei62x64.sys:String) [Rename-Item], Unauthorized
AccessException
+ FullyQualifiedErrorId : RenameItemUnauthorizedAccessError,Microsoft.PowerShell.Commands.RenameItemCommand
Checked with computer maker, Puget Systems, and they sent a list of updated drivers which had no impact on this issue since fei62x64 remains.
Any thoughts on how to either rename this file or another way to allow me to enable to turn on core isolation with fei62x64 listed as incompatible driver
Okay I think my best solution is to use pnputil, a microsoft utility which allows you to delete a driver. Obviously be good to do a backup before using something like this. pnputil will allow you to delete individual drivers
Related
My company owns several business licenses for Xamarin.Android, and we'd like to use this on our CI server. However, it seems that I'd need to install the full Xamarin suite on my CI server including Visual Studio Pro to make this work. My question is, using the vanilla Xamarin.Android package, how can I activate it?
It seems that installing this on its own adds the Xamarin.Android tools and libraries to build with but there is no way to activate it that I can find, so when I attempt to build using MSBuild, the build fails with this error:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(299,2): error XA9008: Building from the command-line requires aÿBusinessÿLicense.
Now, after some googling, I have found that the activation tool is called "mandroid.exe", which can be found in C:\Program Files (x86)\MSBuild\Xamarin\Android - although I have found references to this being in the 64-bit program files too.
Unfortunately, I can't find any suitable documentation on this tool. Every time I find a thread where someone discusses this, someone from Xamarin jumps in and says "contact support#xamarin.com". After a while I did that but two business days later there still is no response and I've got deadlines to meet so I thought it might be helpful for everyone involved for us to publicly document this process.
The best thing I've found comes from a thread on the Xamarin mailing list which references this invocation:
mandroid.exe --activate --name "NAME" --company "COMPANY" --email "EMAIL" --phone "PHONE" --code "ACTIVATION CODE"
I have also discovered another variant of this invocation that looks like this:
.\mandroid.exe –activate –activation-name="NAME" –activation-phone="PHONE" –activation-company="COMPANY" –activation-code="CODE" –activation-email="EMAIL"
I've tried many permutations of my account data here using both invocations - using the activation code from the products page on the Xamarin store. No matter what though, this error occurs:
\mandroid.exe : monodroid: error XA9997: Incomplete data provided to complete activation
In the "problems activating?" section of the products page, it says this:
In Mono for Android 1.0.21316 and later, if activation within Visual Studio fails then a MfaActivation.dat file will be created within the Documents folder. Select this file below.
Perhaps there's some way to force this file to be created by mandroid.exe? That would be very helpful. While I imagine that offline activation is the only way to make this work, I would accept any answer that involves uploading MfaActivation.dat or otherwise invoking the online activation machinery as well.
Update - I'm afraid that the below steps no longer work. Xamarin has updated their activation system to activate by a different method for newer versions.
In the end I had to install Xamarin Studio as part of the Chef configuration and just instruct administrators to manually activate the software as part of creating a new build node. I had no luck trying to reverse engineer a fix, and if I did, it would probably just break again.
It turns out that I almost had it correct. The second invocation I specified is actually the correct way to call this command but the -- part was apparently converted to a – token by some blog software somehow.
The --activate verb will perform an online activation with Xamarin's servers, so I'm still not sure how you'd do it without an internet connection.
For reference, here is how I did it:
mandroid.exe -v --activate --activation-name "(NAME)" --activation-phone "(PHONE_" --activation-email "(EMAIL)" --activation-company "(COMPANY)" --activation-code "(CODE)"
I'm not sure about the significance of the -v switch, but perhaps that would make it output debugging info if there was a problem.
You must enter all the information exactly as specified on your products page - select one of your licenses and select "problems activating?". However, you will need to enter the licensee name - i.e. the user who owns the license in the --activation-name parameter which must correspond to the --activation-code parameter.
After doing this you can call mandroid with the --activated switch which returns an exit code:
PS> & .\mandroid.exe --activated
PS> $LastExitCode
0
You will also be able to reload the products page and you should see that your license for the chosen user has a new computer registered to it.
This does use up another activation but if you e-mail the support team you can sign the build server agreement and then I assume they can set you up with additional activations for your build nodes.
It's a shame that this wasn't documented better because this has wasted my time for several days. Hopefully this will be helpful to someone else with the same situation.
From Xamarin documentation, we can see
http://docs.xamarin.com/guides/cross-platform/ci/configuring_tfs/
"Visual Studio Professional (or greater) must be installed on the Team
Foundation Server along with licensed copies of Xamarin.Android and
Xamarin.iOS to support development of Android and iOS mobile
applications via the Team Foundation Server."
So I assume that in all cases you need to have VS + Xamarin products installed and activated.
I might be wrong, so the best way is to contact Xamarin support, http://xamarin.com/support
While testing the downgrade functionality of one of our WiX-built MSIs, I have noticed something odd.
I have allowed downgrades in the MajorUpgrade element and I have scheduled that element to be afterInstallInitialize (but I have tried it thoroughly with afterInstallValidate and I experience the same problem; we can't have it after that action, but I thought I'd test it).
Many of the files (e.g. the DLLs in our Service's bin folder) are of a higher version, with each release; therefore, the version we are downgrading to includes files of a lower version. Yet all of those files are installed fine, during the downgrade, apart from the Service EXE files; further, the Services are also not installed in Windows.
Considering all of the above, after spending two days on this problem, and after much searching, I appear to be at a loss.
I have tried two things that seem to provide some hope:
1) I have tried setting the REINSTALLMODE property to amus. This ensures that the EXE files are installed, along with the Windows Services. But most things I read about that property warn against using it, and I even have to surpress ICE40, in order to get my package to build, when setting that property. This all concerns me, as I am not sure what negative effects could be missed, if I use this property in my MSI files.
2) When I remove the KeyPath attribute from the File elements that mark up the Service EXE files and place that attribute on the Component element instead, the Service EXE files are installed onto the system during the downgrade, but the Services are still not installed in Windows. After looking into this, it seems that the KeyPath attribute must be on the File element, if I'd like Services to be installed. So it seems to me as if this idea will not help.
Any help or advice would be very much appreciated. We really could do with providing downgrade functionality.
Thank you all for your time.
MSI is essentially opposed to the idea of downgrades. Once a file is on the machine, MSI tries very hard to keep the latest version of the file around as, among other reasons, downgrading the file can re-introduce a security vulnerability. I'd suggest not directly supporting downgrades; instead, you can show a message that tells the user to uninstall the higher version first.
My solution was to use Burn to provide the 'downgrade' functionality using a custom bootstrapper application.
The bootstrapper detects, downloads, and then installs the new version. In the case of a downgrade it performs an uninstall prior to the install. However, this requires that you execute the bootstrapper of the currently installed version to get the ability to uninstall.
You then also need to worry about any state that will be removed as a consequence of uninstalling, this needs to be preserved the same way as you would during an upgrade.
Using Wix, to allow downgrading and still have the Windows Service install properly on downgrade, use the following combination:
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
<MajorUpgrade Schedule="afterInstallInitialize" AllowDowngrades="yes" />
I was also using WixSharp to generate the .wxs file and used this code to do so:
// https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode
// a = Force all files to be reinstalled, regardless of checksum or version.
// m = Rewrite all required registry entries from the Registry Table that go to the HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT registry hive. Rewrite all information from the Class Table, Verb Table, PublishComponent Table, ProgID Table, MIME Table, Icon Table, Extension Table, and AppID Table regardless of machine or user assignment.Reinstall all qualified components.When reinstalling an application, this option runs the RegisterTypeLibraries and InstallODBC actions.
// u = Rewrite all required registry entries from the Registry Table that go to theHKEY_CURRENT_USER or HKEY_USERS registry hive.
// s = Reinstall all shortcuts and re-cache all icons overwriting any existing shortcuts and icons.
project.AddXml("Wix/Product", "<Property Id=\"REINSTALLMODE\" Value=\"amus\" />");
// Allow downgrading versions
// https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
project.AddXml("Wix/Product", "<MajorUpgrade Schedule=\"afterInstallInitialize\" AllowDowngrades=\"yes\" />");
See also:
https://learn.microsoft.com/en-us/windows/win32/msi/reinstallmode
https://wixtoolset.org/documentation/manual/v3/xsd/wix/msiproperty.html
https://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html
I created customized brush using gimp.While I tried to save it in gimp directory, following error is obtained."'C:\Program Files\GIMP 2\share\gimp\2.0\brushes\mybrush.gbr' for writing: Permission denied". Please help me how can I get access permissions.
I assume you're on Windows 7. Whenever you got errors that you do not have the correct rights while saving items/files you need to get administrator/root access on GIMP.
In windows you can do this by rightclicking the .exe/icon and look for the option "Open/Run with Administrative rights".
Not sure how one would do it in Linux but I assume you'll have to run your program with sudo and/or root access by -su.
When you have administrative rights you should be fine saving everything on the desired location
By default, in Operating Systems where normal users can't create files anywhere on the disk (like any age Linux, or Windows 7), GIMP's default resource folders are installed with the program, and are system wide. These folders are not writable by users without administrative rights.
Running GIMP with administrative rights could, of course, override this problem, but this is not "the right thing to do". What you have to do is go to edit->preferences and on the appropriate Folder resource, create a new folder, this time as a normal user, where those resources will be kept.
From them on, write operations will happen on the newly created folder.
Right-click on .exe (.exe-icon) ---> Properties ---> Compatibility ---> Input Setting = Uncheck "Turn off advanced text services for this program"
- Hope that Help !
We have a Delphi program whose task is like a service program. It watches a particular folder for a certain period, and it works great on Windows XP and 2003, but on Windows 2008r2 64bit, when it wants to create an automatic folder, it will show this message:
The ... folder does not exist. The file may have been moved or deleted.
This message causes the program to halt, which is not good; it should not be interrupted.
What can I do about this?
P.S.: I really don't have any idea whether to post my problem in Stack Overflow or Server Fault, so I've guessed it should be here.
It's likely the VirtualStore, if you're trying to store beneath Program Files (either one). See my writeup:
http://www.clipboardextender.com/off-topic/vista-program-files-hide-and-seek
You've left out the ... folder name. While that's understandable, it wouldn't happen to have anything to do with program files (which on x64 will be split in 2 directories) would it?
Windows Server 2008 is able to use 'virtual' file pathes. That means: 'what you see is not what you get'. The Windows Explorer just shows you the 'display' name. Check the file path with cmd.exe, if the path you are trying to use does realy exist.
The reason is of cause the File Virtualization (see for example http://msdn.microsoft.com/en-us/library/bb756960.aspx and http://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx).
Because we on stackoverflow.com and not on serverfault.com I want add to all other answers that you can use Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection and Wow64EnableWow64FsRedirection functions (see http://msdn.microsoft.com/en-us/library/aa365743.aspx) to control the File Virtualization in your program. An example of the usage of this functions in C# you can find here http://www.pinvoke.net/default.aspx/kernel32.wow64disablewow64fsredirection.
You'll need to tell us the exact path and how do you go about constructing it. It can be as simple as the app not using env variable expansion but assuming that user's folders are where they were before.
Path virtualization (there are 2 kids actually) that people mentioned will hit you only if your app is trying to mess with system folders.
More puzzling problem will hit you if you are not expanding env vars like APPDATA, LOCALAPPDATA etc. and not expecting that there's more of them on Win7 and 2k8. Not only that default paths of user's files changed but some of them can also be on network shares - for the same user. So if you were running based on expectation that all user's stuff will be at definite paths under say %USERPROFILE% you can get hit by several surprises. Also notice %ProgramData% .
Fastest way to find out - open cmd.exe, run set and if you see some paths that you are constructing in alternative ways, take notice that you need to start expanding env vars for them. Then open cmd.exe as a 32-bit app and check set again. You can also pick them up via Process Explorer from some running 32-bit or 64-bit app.
Switching your app to 64-bit build will resolve most of virtualization issues but not the env var expansion. Also if your app is touching system folders you need to request elevated run from the code or even better make the manifest and declare it there. Then OS will yell at user up front if his UAC is on and your app will avoid that 2nd virtualization. BTW, virtualization is controllable via group policies so it might be present on some boxes and missing on others.
I am having some trouble updating UMDF drivers using "devcon" during a
standard code-deploy-debug cycle. The problem is that "devcon update" isn't
really updating anything unless the version number or the date of the DLL
file and the INF file has changed from what is stored in the system's driver
cache folder. After a maddening series of experiments I've discovered that
one way to force the thing to use the latest files is by doing the
following:
Change the parameters passed to
"stampinf.exe" in "makefile.inc" by
explicitly setting a version with
the "-v" option.
Modify the
resource script file ("DRIVER_NAME.rc") to first define
VER_USE_OTHER_MAJOR_MINOR_VER
before including "ntverp.h" and then
explicitly define
VER_PRODUCTMAJORVERSION and
VER_PRODUCTMINORVERSION. You'll
note that this system does not allow
us to change the build and the
revision numbers. On Win7 this
seems to be fixed at 7600 and 16385
in "ntverp.h". Is this by design?
So, I first modify "makefile.inc" and set the "-v" option to something like
"1.1.7600.16385" manually incrementing the minor version for every single
build and then modify the RC file and update VER_PRODUCTMINORVERSION with
the same number.
Alternatively, if I run a command prompt under the SYSTEM account and go and
delete the driver cache folder in
"C:\windows\system32\DriverStore\FileRepository\DRIVER FOLDER" before
running "devcon" then that works too.
Now, I am thinking I am missing something fairly basic here as this seems to
be a rather painful way of doing it. Please help! Thanks!
Why can't you just unplug the device and replace the unloaded DLL? You shouldn't need to reinstall the driver, just replace the module. Note that you shouldn't do this during production or anything that has to do with customers, but if you're writing a driver, just slam in the new module with the same version number.
On Win7 this seems to be fixed at 7600 and 16385 in "ntverp.h". Is this by design?
Yep, at least until the next service pack
As Paul Betts has suggested above, the way to go seems to be to simply replace the UMDF DLL directly in the driver folder (for e.g. c:\windows\system32\drivers\umdf\) after disabling the device either in the device manager or using "devcon". I'd asked this question on Microsoft's device drivers newsgroup before posting here but hadn't got a satisfactory response - but some folks ended up responding there after I posted here! So I'll put up a link to that post as well:
http://bit.ly/6PDxKT