Is Inspect a part of the Windows 10 standalone SDK?
Is there any alternative application to "inspect" for windows 10?
I want to install "inspect" tool on my machine running windows 10 build 10586 (for testing purpose).
According to Inspect documentation on MSDN it is not described if it is a part of win 10 sdk also or only upto win 8.1.
Also is there any alternative tool for "Inspect" to debug on windows 10?
Since 10.0.15063 the directory of the tools has changed. See the changelog:
To improve the developer experience, tools and metadata will lay down in versioned folders.
This will allow developers to isolate the SDK and tools between
releases.
You have to put the version of the Windows SDK between bin and x64 (or x86 or arm)
For me inspect is in the folder C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64
The folder C:\Program Files (x86)\Windows Kits\10\bin\x64 (without the SDK version) exists, but does not contain the inspect tool.
Needed Components for "Inspect":
Inspect is, indeed, included in the Windows 10 "standalone SDK" available from Microsoft here. Note the installer stub allows you to download several "features" (additional toolkits and utility packages) besides the Windows SDK proper. If all you want is Inspect, you can save yourself downloading about 300MB (650MB installed) of unnecessary packages by deselecting everything except "Windows Software Development Kit":
As for an alternative to Inspect, this answer suggests Windows Detective. Not having used the tool, I can't speak personally to its safety or suitability for the purpose, so caveat emptor, YMMV, May the Force Be With You and all that.
If you are using Visual Studio 2017, you can also install Inspect via the Visual Studio Installer.
All you need is to install the following feature, or a later version:
Windows 10 SDK (10.0.15063.0) for UWP: C#, VB, JS
After doing that you should find inspect.exe in the following location:
C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64
In windows 10, Inspect.exe is available at C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\arm64.
Steps in Jul 2022
https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/
Download the 22621.1.220506-1250.ni_release_WindowsSDK.iso and launch it, windows 10 will automatically mount it as D.
Install this: d:\Installers\Windows SDK for Windows Store Apps Tools-x86_en-us.msi
After that, inspect.exe will be available in C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x86\inspect.exe
If you can't find the tool in the Windows 10 SDK, you should be able to download and install the Windows 8.1 SDK from the SDK archive page:
Windows and Windows Phone SDK archive
Inspect is available here: C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64. Based on version changes you can find it in one of the versions under the x64 folder.
Regarding the second part of the question, about an alternative, I've tested an interesting one that works very well, FlaUInspect. Is targeted for an "automation perspective", giving details useful for writing automated tests for example.
Is open source under an MIT license. Can be found on GitHub.
Related
So, I've got Windows 10.0.18358.1 installed, latest Visual Studio (17, not bothering with 19 as of yet), updated (Insider) Windows SDK which should include the DX12 SDK.
And, yet, I have no DXSDK_DIR environment variable set.
I can see all of the DX and D3D headers and libs in the windows kits folder, but their distribution doesn't really correspond to a typical include/bin/lib structure.
Suggestions on how to correct this? I'd settle for copy of anyone's set output
that has this working.
(DirectML tag is because that is the feature that I require, and the source of all of this insanity.)
The DXSDK_DIR variable was only used by the legacy DirectX SDK and the 'beta DirectX 12 SDK' test vehicle, it's not used by the Windows 10 SDK as the standard WindowsSDKDir already includes the required headers & libraries.
If you are building with the Visual Studio build system, you don't have any special setup to use the DirectX 12 headers as they are all in the path already. Likely, your project is set to use the 10.0.17763 Windows 10 SDK by default, so to use the Windows 10 Insider SDK, you'll need to modify the project settings <WindowsTargetPlatformVersion> element to reference the newer 10.0.18xxx version.
If you are using some more manual build system, then you should use the include paths for the Windows 10 SDK side-by-side structure:
%WindowsSdkDir% is typically "C:\Program Files (x86)\Windows Kits\10\"
%WindowsSDKVersion% is something like "10.0.17763.0\"
%arch% is "arm", "arm64", "x64", or "x86'
INCLUDE=%WindowsSdkDir%include\%WindowsSDKVersion%shared;
%WindowsSdkDir%include\%WindowsSDKVersion%um;
%WindowsSdkDir%include\%WindowsSDKVersion%winrt;
%WindowsSdkDir%include\%WindowsSDKVersion%cppwinrt
LIB=%WindowsSdkDir%lib\%WindowsSDKVersion%um\%arch%
See Microsoft Docs and this blog post
The Windows 10 SDK does not include utilities which are instead shared source. For D3DX12, you can obtain the latest header from here
You may also want to look at DirectX Tool Kit for DX12, DirectXTex, and DirectXMesh
For historic and usability reasons, DirectXMath is part of the Windows 10 SDK, but you can also get the latest version from GitHub. The recent Windows 10 SDKs also include the HLSL compiler/D3DCompile API including both the older FXC.EXE and the new Shader Model 6 DXC.EXE.
You may also find the Visual Studio templates on directx-vs-templates useful.
I would suggest reverting to the previous build and flagging the issue in the Feedback Hub. Also, if you haven't already, run chkdsk before and after install, just in case.
I just made a clean instalation of Qt5.5 with QtCreator and Visual Studio 2013 Express for desktop (C++).
However there is no Auto dettected Debug option on the default kit.
Is that a normal behaviour ?
How can I debug my msvc2013 Qt application?
Should I mannualy add a new debbuger?
Here is screenshots of my Qt.
You have to have an appropriate Windows SDK installed as SDK 8.1 in my case:
It expects to find CDB.exe matching the bitness of your project 32/64 bit. And in case if it is still not found, find it manually on your PC local hard drive.
Qt privides a guide on how to set up a debugger. I had the same problem as you and followed the guide. Look at the section "Installing Native Debuggers", it provides you a link to the download page of the debug tools for Windows.
On that Microsoft page, chose the version of WDK that suits you (for me it was WDK 8.1 Update (for Windows 8.1, 8, and 7 drivers)). Download and install the WDK on your machine.
After the installation is done, go the Qt's "Manage Kits" to the "Debuggers" section. Add the path of the debugger that you just installed. Mine has a path C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64\cdb.exe. I assume yours will be similar. Add the debugger to the "Kit" configuration you are using. Now your debugger should work.
Running the WindowsSdkVer.exe shipped with Platform SDK 7.1 does not work.
None of the .BAT files in VS 2005 get updated.
can anyone please tell me how to correct this?
Also, how do I verify that VS2005 is using Platform SDK 7.1?
There are several articles for this in MSDN but none of them for above configuration.
Also, none of them describe the concrete way / definate way of verifying this
You could try to manually set the include and lib paths of the VS environment under
Tools->Options->VC++ Directories
or something like that (it's been a while).
For verification, you can add the /showIncludes parameter to the additional compiler options of the project, and /verbose:lib to the additional linker options to double check that the correct headers/libraries are being used when compiling/linking the project.
IIRC there was some kind of incompatibility between one of the newer versions of the SDK (could have been version 7) and using VS2005, but I can't recall off hand what that was.
You can use below method for using Windows SDK 7.1 with Visual Studio 2005.
Configuring Visual Studio for Visual C++ Development with the Windows SDK
In the link , you can find the contents with
"To use the Windows SDK Configuration Tool in Visual Studio 2008".
Even though it has such title, you can use the same procedure also for VS2005.
Start the Windows SDK Configuration Tool by clicking Start, then All Programs, then Microsoft Windows SDK v7.1, and then Visual Studio Registration.
Right-click Windows SDK Configuration Tool and then click Run as
administrator.
In the Windows SDK Configuration Tool, in the list, select v7.1.
Click Make Current.
I want to write some simple code using DDK - but i don't know even how to compile some demo code that i download.
How to compile this thing ?
Is there some simple editor / IDE that i can use ?
Is there some way to use visual studio to write and compile DDK ?
Generally the WDK consists of a command-line tools. No IDE or etc. However with some efforts it's possible to setup the MS standard IDE (MSVC2005/2008/2010).
First download and install the latest WDK package (from the official MS website). Go into
StartMenu -> Windows Driver Kits -> WDK xxxx.xxxx.x -> Build Environments.
There you'll find a list of build environments. Each one is just a shortcut to cmd.exe, with plenty of environmental variables set accordingly. Those are build environments for different Windows version, plus for each you have a free/checked configurations, which is equivalent to user-mode's Release/Debug builds.
In order to build the driver you should launch one of those shortcuts. Then, in the command prompt, go into the source code's directory and run build batch command. The rest is determined by the makefile residing in the selected directory.
It is possible nevertheless to use the standard IDE for driver development. That is, use vcproj (or vcxproj in MSVC2010) instead of makefile. This however requires setting many build parameters.
Currently there are two main paths to choose from:
1. For drivers running on Windows 7 and above:
Since Visual Studio 2013, you can use Visual Studio's built-in integration for working with WDK projects, which is a full blown IDE for driver development.
Sample screenshot from Visual Studio 2015 + WDK 10:
There is also a short guide from Microsoft on what one needs to get started. The guide includes links to downloads of Visual Studio, WDK and samples - Get started with Windows 10, Visual Studio, and the WDK:
Used together, Visual Studio 2015 and WDK 10 provide an integrated
development environment for creating efficient, high-quality drivers
for devices running Windows 10. This release of Visual Studio includes
the Visual Studio Tools for Windows 10 and the Microsoft Windows
Software Development Kit (SDK) for Windows 10.
In short you need to install Visual Studio 2015 with Update 1 and WDK 10. Your OS need to be Windows 7 or newer (desktop only, not server).
2. For drivers running on Windows XP:
If you need to stick with older WDK 7.1 (eg. for Windows XP support), then this guide from Donald D. Burn can be a good start - Getting Started with Windows Driver Development:
WDK MVP Donald D. Burn shares his experience and insights about tools
for creating a device driver for Microsoft Windows, with information
about debugging, testing tools, and techniques that can help you find
and fix bugs early in development.
...
Updated with changes to the tools, build environment, and best
practices from the Windows Server 2003 Service Pack 1 Windows Driver
Kit (WDK) to the Windows Driver Kit (WDK) Version 7.1.
Choosing this path usually requires compiling drivers in command line via Build Environments, as described by valdo's answer. As for coding you can use an editor of your choice.
I'm having a problem on my TeamCity CI build server where during compilation I get the following error:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(2342, 9): error MSB3086: Task could not find "AL.exe" using the SdkToolsPath "" or the registry key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A". Make sure the SdkToolsPath is set and the tool exists in the correct processor specific location under the SdkToolsPath and that the Microsoft Windows SDK is installed
I've found similar reports from a year ago when people were upgrading to .NET 3.5, for example this one. In that case, installing the latest SDK solved the issue, however I have already installed the latest SDK (Microsoft Windows SDK for Windows 7 and .NET Framework 4) on my build server. The MSBuild tools are all there on the server, in a folder called
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
and AL.exe exists in
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools
However the registry key mentioned in the error message does not exist. So, it seems like there is something wrong with the installation/configuration of MSBuild. This error only happens for projects that have embedded resources, which require AL.exe.
As you have install the latest SDK (I'm assuming that's v7.1)
Go to "Microsoft Windows SDK v7.1" from the Start menu
Select "Windows SDK 7.1 Command Prompt" and enter
cd Setup
WindowsSdkVer -version:v7.1
This will tell msbuild to use that version of the tools without needing to do any scary registry editing.
Even though the question is quite old but it still appears in the top of google search results so I decided to post my solution as well. I have trapped into same issue while during TeamCity setup on Windows Server 2016 and Windows 10 Pro.
I have installed Microsoft Build Tools 2015 and Windows 10 SDK (Only tools for .NET 4.6.2) and got the error from question.
The missing puzzle was to set environment variable: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools.
After setting environment variable MSBuild was able to resolve all needed tools including AL.exe and build succeeded.
Please let me know if same can be achieved by setting values in registry, but otherwise environment variables also works very well in this case and no installation of VS is needed.
You also need to apply the following registry fix to update msbuild to point to the V7.1 sdk values.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0]
"MSBuildToolsPath"="C:\\WINDOWS\\Microsoft.NET\\Framework\\v4.0.30319\\"
"MSBuildToolsRoot"="C:\\WINDOWS\\Microsoft.NET\\Framework\\"
"FrameworkSDKRoot"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1#InstallationFolder)"
"MSBuildRuntimeVersion"="4.0.30319"
"SDK40ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDK-NetFx40Tools-x86#InstallationFolder)"
"SDK35ToolsPath"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Microsoft SDKs\\Windows\\v7.1\\WinSDKNetFx35Tools#InstallationFolder)"
"MSBuildToolsPath32"="$(Registry:HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\MSBuild\\ToolsVersions\\4.0#MSBuildToolsPath)"
I had the same problem there, here's my simple answer to this.
After you have installed the Microsoft Windows SDK 7.1 on the TeamCity Server.
In Regedit Change this key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
to
$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx40Tools-x86#InstallationFolder)
Follow the below steps. This worked perfectly to me. Saved my time.
1- Right-click the My Computer icon and choose Properties, or in Windows Control Panel, choose System.
2- Choose Advanced system settings.
3- On the Advanced tab, click Environment Variables.
4- Click New to create a new environment variable under User variable section.
5- Variable name: TargetFrameworkSDKToolsDirectory
6- Variable value: TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
Variable value depends on your SDK installation path.
7- Click OK and Save all windows.
8- Restart Visual Studio.
I have a simple, effective fix.
The problem seems to be that the tools version delivered with Visual Studio is version 7.0A, while the version delivered with the Windows SDK is version 7.1. That's all very well, but MSBuild.exe is still looking for the version 7.0A registry keys, which don't exist. This has to be a bug!
Looking in my registry, all the information for V6.0 and V7.1 is present and correct. So my solution is simple. I created a registry link that makes an alias of the 7.1 keys.
It's not possible to create registry links using the built-in tools, so I downloaded a little utility called 'regln' from here.
C:>regln-x86.exe "\Registry\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A" "\Registry
\Machine\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1"
Job done. MSBuild now works perfectly on the TeamCity server.
Add a system env variable TargetFrameworkSDKToolsDirectory
like this:
TargetFrameworkSDKToolsDirectory=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.2 Tools
restart VS
Ran into the same issue setting up a new build server on Windows 10.
Found and installed the latest (at the time) Microsoft Windows SDK for Windows 7 and .NET Framework 4 and that solved the problem.
We recently had this problem trying to get our .Net 4.0 builds working. We found that the location of al.exe had changed between where the original MSBuild that came with .Net 4.0 looks, and the Visual Studio SDK for .Net 4.0 (which was released later).
Since the only standalone installation of the SDK tools available is the one we had already installed without success (the one you mentioned), the only solution we could think of was to install Visual Studio on the build agents. We put Visual Studio 2010 Express (to keep the installation as lightweight as possible) on there and the problem went away. Not a pretty solution, but it did work - installing VS2010 also installs the SDK tools of the specific version that MSBuild appears to be looking for.
This is a problem that really shouldn't happen, but there didn't seem to be a way of making MSBuild look in the correct place for the tools, even hacking around in the registry.