MozillaBuild 2.0 does not detect WinSDK installed with Visual Studio

RESOLVED FIXED

Status

mozilla.org
MozillaBuild
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Phoenix, Assigned: Phoenix)

Tracking

({regression})

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

2 years ago
Created attachment 8660321 [details] [diff] [review]
Return check for other SDK installation place

Updated MozillaBuild to version 2.0, get "No Windows SDK found. Exiting." message after starting start-shell.bat. MozillaBuild 1.11 is working fine. Reason: .bat file searching only for standalone SDK installation, but unable to detect SDK installed with Visual Studio.
Attached patch resolving this issue.
Attachment #8660321 - Flags: review?(ryanvm)
Interesting, can you share more details about your system? I'm also running with MSVC2013+WinSDK installed as part of that (rather than standalone) and everything gets detected fine. I'm curious about what might be different such that it isn't working for you.
(Assignee)

Comment 2

2 years ago
Not sure what details is you asking for, but will try anyway:
OS: Win7 x64
VS: Currently I have VS 2013 Community Edition, before it was VS 2010 Express, not sure if I uninstalled it before installing VS 2013, or after.
SDK: I had SDK 7.0 installed, SDK 8.1 came with VS 2013.
There was installations of other applications, shipped along with SDK 8.0/8.1 (debug/appcompat/wpr), they are living in both Program Files/x86, but SDK 8.1 is present only Program Files (x86).
Now let's look on current .bat file, for finding SDK path it first looks into
HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Products
where it finds guid {5247E16E-BCF8-95AB-1653-B3F8FBF8B3F1} for "Windows Software Development Kit DirectX x64 Remote x64"
Next check goes into
HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Roots
Key KitsRoot81 contains value "C:\Program Files\Windows Kits\8.1\", but there are no SDK there, so next check for Include\um\Windows.h fails.
Hive
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs
have three sub-hives, for 7.1A/8.0A/8.1A, but latter two contain information only about .NET SDKs
Hive
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows Kits\Installed Products
have a lot more information about SDKs, there are listed guid {A1CB8286-CFB3-A985-D799-721A0F2A27F3}, which is used in .bat for x32 systems, and it is named "Windows Software Development Kit DirectX x86 Remote x86". Also, there are two guids, {5D5CFAD6-9F93-8C63-3EB0-B6A0D3D4BD12} and {FA69BA1C-67A2-D677-14C3-2A4B590294D0}, which are both contain value "Windows Software Development Kit x86", so looks like current guids in .bat may not be correct (looks like Makoto picked not right ones in Bug 950447, and I didn't re-check that)
Last, hive
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows
have sub-hives for 7.1A/8.0/8.0A/8.1/8.1A, and those without A have key "ProductName" containing "Microsoft Windows SDK for Windows 8.0(1)", and correct path in InstallationFolder key
Comment on attachment 8660321 [details] [diff] [review]
Return check for other SDK installation place

Interesting, so your KitsRoot81 is somehow pointing at C:\Program Files instead of C:\Program Files (x86)?

I'm still trying to understand how you got into the state you're in. On my system (Win10 x64 installed after a clean format + MSVC2013 Community Edition), my KitsRoot81 is pointing at "C:\Program Files (x86)\Windows Kits\8.1\" and I didn't install any extra SDK stuff, just what came with MSVC by default.

But ultimately, rather than take the patch as-submitted, I'd probably lean towards just adjusting the existing logic to look at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.1 by default if it is proven to be a more reliable test. But is it possible that this will end up regressing bug 950447? Maybe not since MSVC + Bundled SDK is all we support these days and that wasn't the case at the time.

Also, do we know for sure that HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1 exists on 32-bit installs?
Flags: needinfo?(pppx)
Attachment #8660321 - Flags: review?(ryanvm)
(Assignee)

Comment 4

2 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #3)
> Interesting, so your KitsRoot81 is somehow pointing at C:\Program Files
> instead of C:\Program Files (x86)?
Yes, that may be related to WinDBG or other additional applications installations, because I don't remember in which order I was installing them.

> But ultimately, rather than take the patch as-submitted, I'd probably lean
> towards just adjusting the existing logic to look at
> HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft
> SDKs\Windows\v8.1 by default if it is proven to be a more reliable test. But
> is it possible that this will end up regressing bug 950447? Maybe not since
> MSVC + Bundled SDK is all we support these days and that wasn't the case at
> the time.
I think there should be no regression, but we can switch current check in KitsRoot81 to be fallback in case if primary check doesn't find needed SDK

> Also, do we know for sure that
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1 exists on
> 32-bit installs?
Looks like so, according to
https://msdn.microsoft.com/en-us/library/hh768146.aspx
"All platform SDKs will be installed at HKLM\Software\Microsoft\Microsoft SDKs\[TPI]\v[TPV]\@InstallationFolder = [SDK root]. Accordingly, the Windows 8.1 SDK is installed at HKLM\Software\Microsoft\Microsoft SDKs\Windows\v8.1."
Flags: needinfo?(pppx)
Blocks: 1201520
(Assignee)

Comment 5

2 years ago
Created attachment 8669429 [details] [diff] [review]
Taking different approach

Make HKEY_LOCAL_MACHINE\SOFTWARE\(Wow6432Node)Microsoft\Microsoft SDKs primary place to check for SDK, with HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Roots left as backup
Attachment #8660321 - Attachment is obsolete: true
Attachment #8669429 - Flags: review?(ryanvm)
I'm wondering if we even need the fallback registry check. In general, I'd like to keep this as simple as possible if we can get away with it.
(Assignee)

Comment 7

2 years ago
Created attachment 8672220 [details] [diff] [review]
No fallback for Kits

Not an issue, here we go
Attachment #8672220 - Flags: review?(ryanvm)
(Assignee)

Updated

2 years ago
Attachment #8669429 - Attachment is obsolete: true
Attachment #8669429 - Flags: review?(ryanvm)
Local testing with the latest patch looks good. I've spun an updated 2.1 test build that includes this patch for wider testing.

http://people.mozilla.org/~rvandermeulen/MozillaBuildSetup2.1.0pre2.exe (77.6MB)
SHA1: 473CB6C3491CC3DBD0EF41CB0090CC9316C36DCA
Comment on attachment 8672220 [details] [diff] [review]
No fallback for Kits

I've tested this locally on Windows 10 x64 and Windows 7 x32 with MSVC 2013 Community Edition and no issues have come up so far. I haven't heard of problems with anybody else who's been testing pre-release builds of MozillaBuild 2.1 either.

Thanks for the patch, Phoenix!
Attachment #8672220 - Flags: review?(ryanvm) → review+
http://hg.mozilla.org/mozilla-build/rev/9a2c7cea32df
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.