New WDK for Windows 7 RC and a problem with old one

WH_Tan · May 3, 2009, 10:59pm

Hello folks,

New WDK for Win7 RC is available on MSDN downloads. I think some of you might have downloaded it already.

However I would like to confirm a few thing:

Did you try to uninstall the recent beta WDK? I run into a problem here which mentions the KitSetup is not digital singed. The setup then exits with some error code.
Do you notice the debugging symbols for various Windows 7 RC builds? But where is the checked build anyway?

Thanks & best regards,

WH Tan

OSR_Community_User · May 4, 2009, 2:10am

I had that problem too.

I found if I mounted the old WDK .iso and ran kitsetup from that old WDK,
and removed the old components it seemed to remove the old WDK from my
system.

I also was wondering about the checked builds, and assume it’s not online to
reduce the download bandwidth demand temporarily.

Jan

Hello folks,

New WDK for Win7 RC is available on MSDN downloads. I think
some of you might have downloaded it already.

However I would like to confirm a few thing:

Did you try to uninstall the recent beta WDK? I run into a
problem here which mentions the KitSetup is not digital
singed. The setup then exits with some error code.

WH_Tan · May 4, 2009, 4:21am

Hi Jan,

Thank you very much.
Running KitSetup from the beta ISO did the trick.

Best regards,

WH Tan

Tim_Roberts · May 4, 2009, 12:38pm

xxxxx@gmail.com wrote:

However I would like to confirm a few thing:

Did you try to uninstall the recent beta WDK? I run into a problem here which mentions the KitSetup is not digital singed. The setup then exits with some error code.

I uninstalled the previous beta WDK (7000.0) and installed the RC WDK
(7100.0), in that order, with no problems. I was anticipating a few
issues, given some recent postings, but it was smooth as silk.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

WH_Tan · May 5, 2009, 1:37am

Hi Tim,

Thanks very much for your information.

I installed the new RC WDK, then only realised that I should have removed the beta WDK since it’s a beta. I ran the uninstaller from the Windows control panel and it sounds like windows installer is complaining about the digital sign of the setup program. I used the tips from Jan in recent post and solved the problem.

Meanwhile, I guess the final uninstallation might have wiped away the Windows Device Testing Framework (WDTF) of the RC version. Just to be safe, I’ll reinstall the RC again today.

Best regards,

WH Tan

Petr_Kurtin · May 5, 2009, 6:45am

I have a problem with “build” parameters. I just updated to WDK 7100 and
when I rebuild my driver with the same old paremeters, “build -MIevcZ”
inserts “1>” (cpu or thread id) to the output. However, such lines don’t
“co-operate” with MSVC editor - if you double click on such error line, MSVC
isn’t able to go to that line number.

Compiling - flt_build\snx.cpp
1>errors in directory c:\snx\drivers\snxmain\flt_build
1>c:\snx\drivers\snxmain\snx.cpp(319) : error C2660: ‘SnxRegDeleteTree’ :
function does not take 0 arguments
Compiling - flt_build\callbacks.cpp
…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: 4. kv?tna 2009 4:58
To: Windows System Software Devs Interest List
Subject: [ntdev] New WDK for Windows 7 RC and a problem with old one

Hello folks,

New WDK for Win7 RC is available on MSDN downloads. I think some of you
might have downloaded it already.

However I would like to confirm a few thing:

Did you try to uninstall the recent beta WDK? I run into a problem here
which mentions the KitSetup is not digital singed. The setup then exits
with some error code.
Do you notice the debugging symbols for various Windows 7 RC builds? But
where is the checked build anyway?

Thanks & best regards,

WH Tan

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Pavel_A1 · May 5, 2009, 7:12am

Petr Kurtin wrote:

I have a problem with “build” parameters. I just updated to WDK 7100 and
when I rebuild my driver with the same old paremeters, “build -MIevcZ”
inserts “1>” (cpu or thread id) to the output. However, such lines don’t
“co-operate” with MSVC editor - if you double click on such error line, MSVC
isn’t able to go to that line number.

The -I switch should suppress cpu numbers, so it doesn’t work in wdk 7100?

–pa

Compiling - flt_build\snx.cpp
1>errors in directory c:\snx\drivers\snxmain\flt_build
1>c:\snx\drivers\snxmain\snx.cpp(319) : error C2660: ‘SnxRegDeleteTree’ :
function does not take 0 arguments
Compiling - flt_build\callbacks.cpp
…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: 4. kv?tna 2009 4:58
To: Windows System Software Devs Interest List
Subject: [ntdev] New WDK for Windows 7 RC and a problem with old one

Hello folks,

New WDK for Win7 RC is available on MSDN downloads. I think some of you
might have downloaded it already.

However I would like to confirm a few thing:

Did you try to uninstall the recent beta WDK? I run into a problem here
which mentions the KitSetup is not digital singed. The setup then exits
with some error code.

Do you notice the debugging symbols for various Windows 7 RC builds? But
where is the checked build anyway?

Thanks & best regards,

WH Tan

Petr_Kurtin · May 5, 2009, 7:23am

I use -I switch, but it seems it doesn’t work in wdk 7100 ;(

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: 5. kv?tna 2009 13:12
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] New WDK for Windows 7 RC and a problem with old one

Petr Kurtin wrote:

I have a problem with “build” parameters. I just updated to WDK 7100 and
when I rebuild my driver with the same old paremeters, “build -MIevcZ”
inserts “1>” (cpu or thread id) to the output. However, such lines don’t
“co-operate” with MSVC editor - if you double click on such error line,
MSVC
isn’t able to go to that line number.

The -I switch should suppress cpu numbers, so it doesn’t work in wdk 7100?

–pa

Compiling - flt_build\snx.cpp
1>errors in directory c:\snx\drivers\snxmain\flt_build
1>c:\snx\drivers\snxmain\snx.cpp(319) : error C2660: ‘SnxRegDeleteTree’ :
function does not take 0 arguments
Compiling - flt_build\callbacks.cpp
…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 4. kv?tna 2009 4:58
To: Windows System Software Devs Interest List
Subject: [ntdev] New WDK for Windows 7 RC and a problem with old one

Hello folks,

New WDK for Win7 RC is available on MSDN downloads. I think some of you
might have downloaded it already.

However I would like to confirm a few thing:

Did you try to uninstall the recent beta WDK? I run into a problem here
which mentions the KitSetup is not digital singed. The setup then exits
with some error code.

Do you notice the debugging symbols for various Windows 7 RC builds?
But
where is the checked build anyway?

Thanks & best regards,

WH Tan

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

WH_Tan · May 5, 2009, 1:40pm

2009/5/4 Jan Bottorff wrote:

I also was wondering about the checked builds, and assume it’s not online to
reduce the download bandwidth demand temporarily.

I just noticed that the checked build is posted on Microsoft connect,
under Windows Ecosystem page.

Best regards,

–
WH Tan

Doron_Holan · May 5, 2009, 2:04pm

I just looked at the 7030 wdk and the internal build with the -I switch. The proc#> is surppressed in the output for nearly all messages. It does still appear in the build.err log file and the output which VS sees. I reran with the same build command line in the 6001.18002 wdk and proc#> was not in the err file so it does look like a change.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Tuesday, May 05, 2009 4:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] New WDK for Windows 7 RC and a problem with old one

I use -I switch, but it seems it doesn’t work in wdk 7100 ;(

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Pavel A.
Sent: 5. kv?tna 2009 13:12
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] New WDK for Windows 7 RC and a problem with old one

Petr Kurtin wrote:

I have a problem with “build” parameters. I just updated to WDK 7100 and
when I rebuild my driver with the same old paremeters, “build -MIevcZ”
inserts “1>” (cpu or thread id) to the output. However, such lines don’t
“co-operate” with MSVC editor - if you double click on such error line,
MSVC
isn’t able to go to that line number.

The -I switch should suppress cpu numbers, so it doesn’t work in wdk 7100?

–pa

Compiling - flt_build\snx.cpp
1>errors in directory c:\snx\drivers\snxmain\flt_build
1>c:\snx\drivers\snxmain\snx.cpp(319) : error C2660: ‘SnxRegDeleteTree’ :
function does not take 0 arguments
Compiling - flt_build\callbacks.cpp
…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: 4. kv?tna 2009 4:58
To: Windows System Software Devs Interest List
Subject: [ntdev] New WDK for Windows 7 RC and a problem with old one

Hello folks,

New WDK for Win7 RC is available on MSDN downloads. I think some of you
might have downloaded it already.

However I would like to confirm a few thing:

Did you try to uninstall the recent beta WDK? I run into a problem here
which mentions the KitSetup is not digital singed. The setup then exits
with some error code.

Do you notice the debugging symbols for various Windows 7 RC builds?
But
where is the checked build anyway?

Thanks & best regards,

WH Tan

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Tanya_Radeva · May 6, 2009, 9:08pm

Hi guys,

We had a discussion with Windows Build team today and we think the build*.log should always contain the thread information irrespective on the command line switch. If not, debugging issues using the log would be very difficult.

However, after some simple tests I do not see that having the tread index printed (1> or whatever number is) in the beginning of the build log file in VS breaks the way how VS displays the Error List in VS editor. For my test I built WDK project in VS by using Ddkbuild script. My Build Line is: “ddkbuild -WLH free . -MIevcZ”. I made couple of intentional syntax errors. When I went to the Error List and click on the Errors tab I was able to see all the errors and then clicked on their lines. The VS editor positioned me to the correct source line number. My build output has thread indexes in the beginning of every line.

If you can repro the issue on your machine it will be great to send some steps: what is the WDK version, VS version, ddkbuild script version, etc.

Best regards,
Tanya

Michal_Vodicka-2 · May 6, 2009, 9:18pm

Tanya,

We had a discussion with Windows Build team today and we
think the build*.log should always contain the thread
information irrespective on the command line switch. If not,
debugging issues using the log would be very difficult.

Do you mean it should be there even when -M is not used?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Tanya_Radeva · May 6, 2009, 9:35pm

Hi Michal,

Nice to hear from you!

Yes, the therad index (1>) will be there. Depending on how many threads the build utility spawns you can see 1>, 2>, etc. or you can see only 1>, right?

In WDK we have BUILD_MULTIPROCESSOR =1 already set in the setenv.bat, which means build.exe shoudl use the same number of threads as available processors when processing each pass.

The /Mx command line option overrides any values set in BUILD_MULTIPROCESSOR and instructs build.exe to use x number of threads when processing each build pass.

Let me know if you have more questions.

Always glad to help,
Tanya

Michal_Vodicka-2 · May 6, 2009, 9:51pm

Tanya,

I’m sorry but it doesn’t seem as a good idea for me. If I understand
correctly, multi thread build only makes sense when more directories are
built at once. When DIRS are used, not only SOURCES in one directory.
Right? It is not the case for most WDK users. I’d say most developers
outside of MS usually build one driver only.

The problem such a change breaks existing build environments which use
build.exe as a tool to build a driver, not as a tool which control whole
build. Not everybody uses VS as an IDE. I haven’t tried WDK 7100, yet,
but I presume changes in my editor (error processing definitions) and in
our build engine (bash, make, m4 etc.) would take several hours of work.
It wouldn’t be a big problem to add “set BUILD_MULTIPROCESSOR = 0” after
setenv.bat call or adding -M1 to build parameter. If it helps to remove
unnecessary thread info.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Thursday, May 07, 2009 3:34 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] New WDK for Windows 7 RC and a problem
with old one

Hi Michal,

Nice to hear from you!

Yes, the therad index (1>) will be there. Depending on how
many threads the build utility spawns you can see 1>, 2>,
etc. or you can see only 1>, right?

In WDK we have BUILD_MULTIPROCESSOR =1 already set in the
setenv.bat, which means build.exe shoudl use the same number
of threads as available processors when processing each pass.

The /Mx command line option overrides any values set in
BUILD_MULTIPROCESSOR and instructs build.exe to use x number
of threads when processing each build pass.

Let me know if you have more questions.

Always glad to help,
Tanya

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer

Mark_Roddy · May 6, 2009, 11:25pm

I am fine with that as the default behavior but not so fine with not
having a switch to turn it off. Please reconsider.

On Wednesday, May 6, 2009, wrote:
> Hi guys,
>
> We had a discussion with Windows Build team today and we think the build*.log should always contain the thread information irrespective on the command line switch. If not, debugging issues using the log would be very difficult.
>
> However, after some simple tests I do not see that having the tread index printed (1> or whatever number is) in the beginning of the build log file in VS breaks the way how VS displays the Error List in VS editor. For my test I built WDK project in VS by using Ddkbuild script. My Build Line is: “ddkbuild -WLH free . -MIevcZ”. I made couple of intentional syntax errors. When I went to the Error List and click on the Errors tab I was able to see all the errors and then clicked on their lines. ?The VS editor positioned me to the correct source line number. My build output has thread indexes in the beginning of every line.
>
> If you can repro the issue on your machine it will be great to send some steps: what is the WDK version, VS version, ddkbuild script version, etc.
>
> Best regards,
> Tanya
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy

Tanya_Radeva · May 6, 2009, 11:38pm

Hi Michal,

“If I understand
correctly, multi thread build only makes sense when more directories are
built at once. When DIRS are used, not only SOURCES in one directory”

Actually even with a single driver project (SOURCES file only) you can have multiple threads. Build.exe spawns nmake to run tools at different build passes. Each nmake could potentially run in a separate thread - for example - one nmake thread for pass1 to run the cl.exe, another nmake thread to run link.exe at pass2, etc.

When a build a kmdf echo driver on my dual core machine I actually see 2 threads. This is because BUILD_MULTIPROCESSOR = 1 in my setenv.bat. Why use BUILD_MULTIPROCESSOR = 0 when I have such a machine?

In regadrs to VS my argument is that even if we see thread indexes in the build*.log and build*.err I do not believe VS uses build.err to display Error List in VS. What if I build Win32 project or any project without the use of ddkbuild script? Where the VS will take the error results from :-)?

But to be completely honest with you (Doron also mentioned) I do see a bug in having thread indexes in build.err file when run the build.exe in a console window and we are working on it. However, this shouldn’t break the functionality of VS in regard to displaying the build error list.

Let me know if more questions, I’ll be glad to answer,
Tanya

Tanya_Radeva · May 7, 2009, 12:13am

Hi Mark,

Pleasure to hear from you!

“I am fine with that as the default behavior but not so fine with not
having a switch to turn it off. Please reconsider.”

No worries here. We are fixing the build output to not display the thread index if errors, the rest of the behavior is the same and as expected. For example we are fixing 1> in the error lines below. The build line is with -I switch and as you can see lines do not have thread indexes.

BUILD: Compile and Link for x86
BUILD: Start time: Wed May 06 20:59:29 2009
BUILD: Examining c:\winddk\7100.0.0\src\general\echo\kmdf\autosync directory for
files to compile.
c:\winddk\7100.0.0\src\general\echo\kmdf\autosync Auto-cleaning queue for ‘W
DKSamples:x86fre’ (3 of 3 file(s) removed)
BUILD: Building generated files in c:\winddk\7100.0.0\src\general\echo\kmdf\auto
sync directory
Configuring OACR for ‘WDKSamples:x86fre’ -
BUILD: Compiling and Linking c:\winddk\7100.0.0\src\general\echo\kmdf\autosync d
irectory
Compiling - driver.c
Compiling - device.c
Compiling - queue.c
1>errors in directory c:\winddk\7100.0.0\src\general\echo\kmdf\autosync
1>c:\winddk\7100.0.0\src\general\echo\kmdf\autosync\queue.c(56) : error C2220: w
arning treated as error - no ‘object’ file generated
Compiling - generating code…
Linking Executable - objfre_win7_x86\i386\echo.sys
1>link : error LNK1181: cannot open input file 'c:\winddk\7100.0.0\src\general\e…

The thread indexes remain in build.log and build.err for debugging purposes, but this does not disturb the work of VS in regard to displaying the error list.

Best regards,
Tanya

Michal_Vodicka-2 · May 8, 2009, 9:54am

Tanya,

Actually even with a single driver project (SOURCES file
only) you can have multiple threads. Build.exe spawns nmake
to run tools at different build passes. Each nmake could
potentially run in a separate thread - for example - one
nmake thread for pass1 to run the cl.exe, another nmake
thread to run link.exe at pass2, etc.

OK, but build passes are serialized, aren’t they? It doesn’t matter how
much threads are used; build time is the same on single or multi CPU.
Really parallel build is used only with DIRS if I understand correctly.

When a build a kmdf echo driver on my dual core machine I
actually see 2 threads. This is because BUILD_MULTIPROCESSOR
= 1 in my setenv.bat. Why use BUILD_MULTIPROCESSOR = 0 when
I have such a machine?

Have you tried to measure build time with both settings? I’d bet the
results are very similar. The point is it doesn’t matter if multi CPU
build is used or not when only one driver is built.

In regadrs to VS my argument is that even if we see thread
indexes in the build*.log and build*.err I do not believe VS
uses build.err to display Error List in VS. What if I build
Win32 project or any project without the use of ddkbuild
script? Where the VS will take the error results from :-)?

Well, but I don’t use VS and I use build*.* files to process error
messages and build results. It always worked well and it was the
original purposes of these files.

But to be completely honest with you (Doron also mentioned) I
do see a bug in having thread indexes in build.err file when
run the build.exe in a console window and we are working on
it. However, this shouldn’t break the functionality of VS in
regard to displaying the build error list.

Fine, as Mark, I don’t care too much about default behaviour. If there
is a way how to disable indexes, it is fine. Backward compatible way,
please. I have to support multiple WDKs in our build engine.

Thanks,

Michal

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Michal_Vodicka-2 · May 8, 2009, 9:59am

Tanya,

The thread indexes remain in build.log and build.err for
debugging purposes, but this does not disturb the work of VS
in regard to displaying the error list.

I missed this part before…

I’m sorry but this breaks the way how I build drivers for about 13 years
now. I don’t use VS and my editor and our build engine processes
build*.* files to display errors and warnings.

There should be a way how to disable it. If there is any problem which
needs to be debugged, it can be enabled.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Don_Burn_1 · May 8, 2009, 10:06am

+1

I really hate this change, not only does it make the files a lot less
readable and like Michal I use them extensively, it breaks build processes
that parse these files. It is a pain that should not be a default, and
should be disablable.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
Tanya,

> The thread indexes remain in build.log and build.err for
> debugging purposes, but this does not disturb the work of VS
> in regard to displaying the error list.

I missed this part before…

I’m sorry but this breaks the way how I build drivers for about 13 years
now. I don’t use VS and my editor and our build engine processes
build*.* files to display errors and warnings.

There should be a way how to disable it. If there is any problem which
needs to be debugged, it can be enabled.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Information from ESET NOD32 Antivirus, version of virus signature
database 4062 (20090508)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

Information from ESET NOD32 Antivirus, version of virus signature database 4062 (20090508)

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com