DebugView on Win7 64 bit

Robert_Bielik-3 · May 4, 2012, 4:03am

Hi all,

Just updated to a Win7 64 bit system, and now I can’t get DebugView to
show my driver debug printouts, it’s running in admin mode so the
“capture kernel” mode is active. I have a vague memory of this being
resolvable, wasn’t it perhaps some setting in the registry ?

TIA
/Rob

Ken_Johnson · May 4, 2012, 4:19am

Did you tick the show verbose output option? That enables output that does not meet the configured in kernel filter levels to be shown.

S (Msft)

From: Robert Bielik
Sent: 5/4/2012 1:03
To: Windows System Software Devs Interest List
Subject: [ntdev] DebugView on Win7 64 bit

Hi all,

Just updated to a Win7 64 bit system, and now I can’t get DebugView to
show my driver debug printouts, it’s running in admin mode so the
“capture kernel” mode is active. I have a vague memory of this being
resolvable, wasn’t it perhaps some setting in the registry ?

TIA
/Rob

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

Robert_Bielik-3 · May 4, 2012, 4:57am

Skywing skrev 2012-05-04 10:18:

Did you tick the show verbose output option? That enables output that
does not meet the configured in kernel filter levels to be shown.
Yes, but I haven’t had to previously (Vista 32 bit), and it doesn’t
change anything, still no debug output. Anyway, I found the registry
setting:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Debug Print Filter]
“DEFAULT”=dword:0000000f

but it hasn’t enabled the debug printouts popping up

Any other ideas ?
/Rob

S (Msft)

From: Robert Bielik
Sent: 5/4/2012 1:03
To: Windows System Software Devs Interest List
Subject: [ntdev] DebugView on Win7 64 bit

Hi all,

Just updated to a Win7 64 bit system, and now I can’t get DebugView to
show my driver debug printouts, it’s running in admin mode so the
“capture kernel” mode is active. I have a vague memory of this being
resolvable, wasn’t it perhaps some setting in the registry ?

TIA
/Rob

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

mm1 · May 4, 2012, 5:27am

Just to ask the basics, is this a CHK or free build?

mm

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Robert Bielik
Sent: Friday, May 04, 2012 1:57 AM
To: Windows System Software Devs Interest List
Cc: Skywing
Subject: Re: [ntdev] DebugView on Win7 64 bit

Skywing skrev 2012-05-04 10:18:

Did you tick the show verbose output option? That enables output that does
not meet the configured in kernel filter levels to be shown.

Yes, but I haven’t had to previously (Vista 32 bit), and it doesn’t change
anything, still no debug output. Anyway, I found the registry setting:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug
Print Filter]
“DEFAULT”=dword:0000000f

but it hasn’t enabled the debug printouts popping up

Any other ideas ?
/Rob

S (Msft)

From: Robert Bielik
Sent: 5/4/2012 1:03
To: Windows System Software Devs Interest List
Subject: [ntdev] DebugView on Win7 64 bit

Hi all,

Just updated to a Win7 64 bit system, and now I can’t get DebugView to
show my driver debug printouts, it’s running in admin mode so the
“capture kernel” mode is active. I have a vague memory of this being
resolvable, wasn’t it perhaps some setting in the registry ?

TIA
/Rob

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

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

Robert_Bielik-3 · May 4, 2012, 5:30am

Martin O’Brien skrev 2012-05-04 11:27:

Just to ask the basics, is this a CHK or free build?

The driver build is chk x64 win7…

Oh, and before someone asks: I did reboot after setting the DEFAULT
registry value…

/Rob

Robert_Bielik-3 · May 4, 2012, 6:44am

I think I found the problem, but don’t know how to deal with it. In the
build I do this:

disable the driver
copy the new driver .sys file to C:\Windows\System32\drivers\
enable the driver

During the build this “seems” to work, however when checking the .sys
file in C:\Windows\System32\drivers\ it is not updated!??

I’ve used this approach earlier on Vista/32 with no problems at all.

Step 2 is simply:
copy /Y /B /V $(TargetPath) %SystemRoot%\System32\drivers\

where $(TargetPath) points to the .sys file.

TIA
/Rob

Doron_Holan · May 4, 2012, 10:09am

The proper way to update your driver is to remove the old package and apply the new one. The driver store will then make sure the right file is in the drivers directory

d

debt from my phone

From: Robert Bielik
Sent: 5/4/2012 3:44 AM
To: Windows System Software Devs Interest List
Cc: Martin O’Brien; ‘Skywing’
Subject: Re: [ntdev] DebugView on Win7 64 bit

I think I found the problem, but don’t know how to deal with it. In the
build I do this:

disable the driver
copy the new driver .sys file to C:\Windows\System32\drivers\
enable the driver

During the build this “seems” to work, however when checking the .sys
file in C:\Windows\System32\drivers\ it is not updated!??

I’ve used this approach earlier on Vista/32 with no problems at all.

Step 2 is simply:
copy /Y /B /V $(TargetPath) %SystemRoot%\System32\drivers\

where $(TargetPath) points to the .sys file.

TIA
/Rob

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 4, 2012, 10:24am

“Robert Bielik” wrote in message news:xxxxx@ntdev…
> …
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
> Manager\Debug Print Filter]
> “DEFAULT”=dword:0000000f
>
> but it hasn’t enabled the debug printouts popping up

Try 0xFFFFFFFF ?

For me, DebugView output also sometimes disappeared misteriously on win7.

– pa

Robert_Bielik-3 · May 4, 2012, 10:41am

Doron Holan skrev 2012-05-04 16:08:

The proper way to update your driver is to remove the old package and
apply the new one. The driver store will then make sure the right file
is in the drivers directory
Maybe proper, but a whole lot less convenient, and slower, during
development. Besides I’ve done this on Vista/32 for years, no problemo.

That said, the whole problem seems to be one of being able to copy the
file proper, and one of signing. The development driver is not signed at
all, not even test signed, as a devcon status revealed (I guess,
because it reported “The device has the following problem: 52” (gotta
love those messages , whereas a signed driver file does not).

If I manually do the disable/copy(signed checked driver)/enable steps,
it works and I get the debug outputs…

Regards
/Rob

d

debt from my phone

From: Robert Bielik
Sent: 5/4/2012 3:44 AM
To: Windows System Software Devs Interest List
Cc: Martin O’Brien; ‘Skywing’
Subject: Re: [ntdev] DebugView on Win7 64 bit

I think I found the problem, but don’t know how to deal with it. In the
build I do this:

disable the driver

copy the new driver .sys file to C:\Windows\System32\drivers\

enable the driver

During the build this “seems” to work, however when checking the .sys
file in C:\Windows\System32\drivers\ it is not updated!??

I’ve used this approach earlier on Vista/32 with no problems at all.

Step 2 is simply:
copy /Y /B /V $(TargetPath) %SystemRoot%\System32\drivers\

where $(TargetPath) points to the .sys file.

TIA
/Rob

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

Robert_Bielik-3 · May 4, 2012, 12:18pm

Ok, nailed it down to the problem that within the Visual Studio NMake build (even if running it as admin), copy/xcopy don’t work. They happily say “1 file(s) copied”, but the driver .sys file under C:\Windows\System32\drivers\ doesn’t get updated (which was the primary reason I couldn’t see the debug outputs).

If I do the same operation in a cmd window (run as admin), there’s no problem copying the file.

I have no idea how to proceed

Ideas would be appreciated…
/Rob

Tim_Roberts · May 4, 2012, 12:39pm

xxxxx@xponaut.com wrote:

Ok, nailed it down to the problem that within the Visual Studio NMake build (even if running it as admin), copy/xcopy don’t work. They happily say “1 file(s) copied”, but the driver .sys file under C:\Windows\System32\drivers\ doesn’t get updated (which was the primary reason I couldn’t see the debug outputs).

I think I can explain this.

Nmake in Visual Studio is a 32-bit tool. When it refers to
\Windows\System32, the operating system helpfully and stupidly REWRITES
the path to \Windows\SysWOW64. If you look in
\Windows\SysWOW64\Drivers, my guess is you will find your driver there,
lonely and useless.

If I do the same operation in a cmd window (run as admin), there’s no problem copying the file.

I have no idea how to proceed

I would never, ever, ever try to debug a brand new driver on the same
machine where I am doing the development. The cost of a crash is just
too high. You should be using a second machine, using batch files to do
the copying. Even if you insist on one machine, I think you’re going to
want to invoke a batch file to copy the current binary into place.
You’ll need to do that to restart the driver anyway (using “devcon
restart”, for example).

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

OSR_Community_User · May 4, 2012, 12:40pm

Are you trying to build, run and debug the driver on the same machine?

Meanwhile, if the copy only works as admin then you could run Visual Studio as admin.

Tim.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-501948-
xxxxx@lists.osr.com] On Behalf Of xxxxx@xponaut.com
Sent: 04 May 2012 17:17
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DebugView on Win7 64 bit

Ok, nailed it down to the problem that within the Visual Studio NMake build
(even if running it as admin), copy/xcopy don’t work. They happily say “1
file(s) copied”, but the driver .sys file under C:\Windows\System32\drivers\
doesn’t get updated (which was the primary reason I couldn’t see the debug
outputs).

If I do the same operation in a cmd window (run as admin), there’s no
problem copying the file.

I have no idea how to proceed

Ideas would be appreciated…
/Rob

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

Robert_Bielik-3 · May 4, 2012, 3:31pm

@Tim Roberts: It’s not a brand new driver, as I said I’ve been working on it for more than a year. So it is perfectly sensible to run it on the same machine, as anything I’d do would be mere trimmings.

As for VS in 32 bit, you nailed it! Indeed the driver is found in SysWOW64\drivers…

@Tim Green: I think Tim R nailed it, since VS is 32 bit only it runs in WoW64, thereby making it impossible to do.

So I swallowed the red pill and went with Doron’s suggestion, i.e. I make a new installation package (.inf/.sys/.cat) sign it, and do an update with devcon. Not my first choice, but it works fine.

All of this, just to find out there was nothing wrong with the driver, I had only been using an earlier revision (which showed problems). Ah well… what is time anyway…

Thank you all,
/Rob

OSR_Community_User · May 4, 2012, 3:56pm

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-501954-
xxxxx@lists.osr.com] On Behalf Of xxxxx@xponaut.com
Sent: Friday, May 04, 2012 9:30 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] DebugView on Win7 64 bit

As for VS in 32 bit, you nailed it! Indeed the driver is found in
SysWOW64\drivers…

@Tim Green: I think Tim R nailed it, since VS is 32 bit only it runs in WoW64,
thereby making it impossible to do.

Look here: http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.

I haven’t tried it as I just turn it off using Wow64DisableWow64FsRedirection() API.

So I swallowed the red pill and went with Doron’s suggestion, i.e. I make a
new installation package (.inf/.sys/.cat) sign it, and do an update with
devcon. Not my first choice, but it works fine.

It works but it is an overkill. I’m also doing disable/update/enable all the time. From command like running new version driver is matter of few seconds.

Just for the record: I’m running Windows drivers under development on the same machine for about 16 years now. No problem is one is careful. It may depend on the kind of driver, though.

Michal

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

Robert_Bielik-3 · May 4, 2012, 4:05pm

Hi Michal,

Vodicka, Michal skrev 2012-05-04 21:55:

---- 32-bit applications can access the native system directory by
substituting %windir%\Sysnative for %windir%\System32. WOW64
recognizes Sysnative as a special alias used to indicate that the file
system should not redirect the access. This mechanism is flexible and
easy to use, therefore, it is the recommended mechanism to bypass file
system redirection. Note that 64-bit applications cannot use the
Sysnative alias as it is a virtual directory not a real one. ----
Weeehaaaaa!!! Thank you!! Indeed, replacing System32 with Sysnative
works like a charm. Now I’m back to how I want it to work

Regards,
/Rob