Common Buffer

I am getting a STATUS_INVALID_DEVICE_REQUEST while trying to create a
CommonBuffer.

Also more importantly before that status is returned. I hit a breakpoint in
Wdf01000(wonder why?) This does not look like a bugcheck.

Another problem is that I was unable to get the symbols for the same. where
can I find symbols for Wdf01000.sys. I am using the WDF Build 6000

I assume you meant the 6000 build of the WDK, not WDF. I am also
assuing you are using KMDF v1.5 if you are using the WDK.

What OS are you running on? Are you using the public symbol server and
still can’t get symbols? You should also turn on the KMDF verifier
(http://blogs.msdn.com/doronh/archive/2006/05/17/600335.aspx) as well as
the default debug output if you are on Vista
(http://blogs.msdn.com/doronh/archive/2006/11/14/where-did-my-debug-outp
ut-go-in-vista.aspx)

Did this code used to work on a different OS or a previous version of
KMDF?

Can you post the code that is failing?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashok Bruno
Sent: Tuesday, November 28, 2006 8:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Common Buffer

I am getting a STATUS_INVALID_DEVICE_REQUEST while trying to create a
CommonBuffer.

Also more importantly before that status is returned. I hit a breakpoint
in
Wdf01000(wonder why?) This does not look like a bugcheck.

Another problem is that I was unable to get the symbols for the same.
where
can I find symbols for Wdf01000.sys. I am using the WDF Build 6000


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Yes. I am using the WDK, KMDF v 1.5

I am currently running on Windows XP 64 bit. I am connected to the symbol
server and still can’t get symbols. Is this a problem only on XP64, should I
be testing on Vista 64 instead??

I have the verifier turned on. Infact I see this behaviour of the
breakpoint, and then failure of the buffer only after I turned verifier on.

Here’s the code that causes the problem, SRAMDmaEnabler has been created
much before. In this case I am requesting a buffer of 24 bytes or so.
pInternalDMABuffer is a struct that stores description about my DMA buffer.
status = WdfCommonBufferCreate( pDevExt->SRAMDmaEnabler,

pInternalDMABuffer->uiSGTableBufferSize,

WDF_NO_OBJECT_ATTRIBUTES,

&pInternalDMABuffer->SGTableBuffer );

I did not try it on a different OS or a previous version of the KMDF.

Ashok

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I assume you meant the 6000 build of the WDK, not WDF. I am also
assuing you are using KMDF v1.5 if you are using the WDK.

What OS are you running on? Are you using the public symbol server and
still can’t get symbols? You should also turn on the KMDF verifier
(http://blogs.msdn.com/doronh/archive/2006/05/17/600335.aspx) as well as
the default debug output if you are on Vista
(http://blogs.msdn.com/doronh/archive/2006/11/14/where-did-my-debug-outp
ut-go-in-vista.aspx)

Did this code used to work on a different OS or a previous version of
KMDF?

Can you post the code that is failing?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashok Bruno
Sent: Tuesday, November 28, 2006 8:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Common Buffer

I am getting a STATUS_INVALID_DEVICE_REQUEST while trying to create a
CommonBuffer.

Also more importantly before that status is returned. I hit a breakpoint
in
Wdf01000(wonder why?) This does not look like a bugcheck.

Another problem is that I was unable to get the symbols for the same.
where
can I find symbols for Wdf01000.sys. I am using the WDF Build 6000


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

At what IRQL are you making the call? This API is only callable at
PASSIVE_LEVEL. I will ask about the 64 bit symbols

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashok Bruno
Sent: Wednesday, November 29, 2006 4:50 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Common Buffer

Yes. I am using the WDK, KMDF v 1.5

I am currently running on Windows XP 64 bit. I am connected to the
symbol
server and still can’t get symbols. Is this a problem only on XP64,
should I
be testing on Vista 64 instead??

I have the verifier turned on. Infact I see this behaviour of the
breakpoint, and then failure of the buffer only after I turned verifier
on.

Here’s the code that causes the problem, SRAMDmaEnabler has been created

much before. In this case I am requesting a buffer of 24 bytes or so.
pInternalDMABuffer is a struct that stores description about my DMA
buffer.
status = WdfCommonBufferCreate( pDevExt->SRAMDmaEnabler,

pInternalDMABuffer->uiSGTableBufferSize,

WDF_NO_OBJECT_ATTRIBUTES,

&pInternalDMABuffer->SGTableBuffer );

I did not try it on a different OS or a previous version of the KMDF.

Ashok

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I assume you meant the 6000 build of the WDK, not WDF. I am also
assuing you are using KMDF v1.5 if you are using the WDK.

What OS are you running on? Are you using the public symbol server and
still can’t get symbols? You should also turn on the KMDF verifier
(http://blogs.msdn.com/doronh/archive/2006/05/17/600335.aspx) as well as
the default debug output if you are on Vista
(http://blogs.msdn.com/doronh/archive/2006/11/14/where-did-my-debug-outp
ut-go-in-vista.aspx)

Did this code used to work on a different OS or a previous version of
KMDF?

Can you post the code that is failing?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashok Bruno
Sent: Tuesday, November 28, 2006 8:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Common Buffer

I am getting a STATUS_INVALID_DEVICE_REQUEST while trying to create a
CommonBuffer.

Also more importantly before that status is returned. I hit a breakpoint
in
Wdf01000(wonder why?) This does not look like a bugcheck.

Another problem is that I was unable to get the symbols for the same.
where
can I find symbols for Wdf01000.sys. I am using the WDF Build 6000


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Please make sure that the public symbol server is in your symbols path and then please post the out put of the following commands so that we can figure out where the problem is

!sym noisy
!reload wdf01000.sys

thx
d

d,

I figured out early yesterday morning that I was making the call at a wrong
level. I was able to fix that.
I will post the results of the output for the WDF symbols.

Ashok
“Doron Holan” wrote in message
news:xxxxx@ntdev…
At what IRQL are you making the call? This API is only callable at
PASSIVE_LEVEL. I will ask about the 64 bit symbols

Thx
d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashok Bruno
Sent: Wednesday, November 29, 2006 4:50 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Common Buffer

Yes. I am using the WDK, KMDF v 1.5

I am currently running on Windows XP 64 bit. I am connected to the
symbol
server and still can’t get symbols. Is this a problem only on XP64,
should I
be testing on Vista 64 instead??

I have the verifier turned on. Infact I see this behaviour of the
breakpoint, and then failure of the buffer only after I turned verifier
on.

Here’s the code that causes the problem, SRAMDmaEnabler has been created

much before. In this case I am requesting a buffer of 24 bytes or so.
pInternalDMABuffer is a struct that stores description about my DMA
buffer.
status = WdfCommonBufferCreate( pDevExt->SRAMDmaEnabler,

pInternalDMABuffer->uiSGTableBufferSize,

WDF_NO_OBJECT_ATTRIBUTES,

&pInternalDMABuffer->SGTableBuffer );

I did not try it on a different OS or a previous version of the KMDF.

Ashok

“Doron Holan” wrote in message
news:xxxxx@ntdev…
I assume you meant the 6000 build of the WDK, not WDF. I am also
assuing you are using KMDF v1.5 if you are using the WDK.

What OS are you running on? Are you using the public symbol server and
still can’t get symbols? You should also turn on the KMDF verifier
(http://blogs.msdn.com/doronh/archive/2006/05/17/600335.aspx) as well as
the default debug output if you are on Vista
(http://blogs.msdn.com/doronh/archive/2006/11/14/where-did-my-debug-outp
ut-go-in-vista.aspx)

Did this code used to work on a different OS or a previous version of
KMDF?

Can you post the code that is failing?

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ashok Bruno
Sent: Tuesday, November 28, 2006 8:09 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Common Buffer

I am getting a STATUS_INVALID_DEVICE_REQUEST while trying to create a
CommonBuffer.

Also more importantly before that status is returned. I hit a breakpoint
in
Wdf01000(wonder why?) This does not look like a bugcheck.

Another problem is that I was unable to get the symbols for the same.
where
can I find symbols for Wdf01000.sys. I am using the WDF Build 6000


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Here is the output. Is it possible I am using the wrong dlls on the target??
I might have had KMDF ver 1.1 on this machine before.

0: kd> !sym noisy
noisy mode - symbol prompts on
0: kd> !reload wdf01000.sys
SYMSRV:
h:\MsSymbols\Wdf01000.pdb\EBEDE0B6E21A4BA78B00E3FFC8EA726C1\Wdf01000.pdb not
found
SYMSRV:
h:\MsSymbols\Wdf01000.pdb\EBEDE0B6E21A4BA78B00E3FFC8EA726C1\Wdf01000.pdb not
found
SYMSRV: http://msdl.microsoft.com/down
load/symbols/Wdf01000.pdb/EBEDE0B6E21A4BA78B00E3FFC8EA726C1/Wdf01000.pdb not
found
DBGHELP: C:\WinDDK\WDF\KMDF10\symbols\amd64fre\wdf\sys\Wdf01000.pdb -
mismatched pdb
DBGHELP:
C:\WinDDK\WDF\KMDF10\symbols\amd64fre\wdf\sys\symbols\sys\Wdf01000.pdb -
file not found
DBGHELP: C:\WinDDK\WDF\KMDF10\symbols\amd64fre\wdf\sys\sys\Wdf01000.pdb -
file not found
DBGHELP: Wdf01000.pdb - file not found
DBGHELP: Couldn’t load mismatched pdb for Wdf01000.sys
*** ERROR: Module load completed but symbols could not be loaded for
Wdf01000.sys
DBGHELP: Wdf01000 - no symbols loaded

wrote in message news:xxxxx@ntdev…
> Please make sure that the public symbol server is in your symbols path and
> then please post the out put of the following commands so that we can
> figure out where the problem is
>
> !sym noisy
> !reload wdf01000.sys
>
> thx
> d
>

After talking with the sym server folks, we found out you are using a version of KMDF from an RC1 build of the WDK. You need to download the RTM build of the WDK (6000) and use the KMDF coinstaller from this build. The public sym server has the symbols for the 6000 build.

d

Could this be an issue when upgrading KMDF versions. I think I have been
using the 6000 build, but however it could be that the installer thinks that
the RC1 coinstaller already exists therefore it does not need to update
that?

What is the proper way to upgrade KMDF versions of drivers?

wrote in message news:xxxxx@ntdev…
> After talking with the sym server folks, we found out you are using a
> version of KMDF from an RC1 build of the WDK. You need to download the
> RTM build of the WDK (6000) and use the KMDF coinstaller from this build.
> The public sym server has the symbols for the 6000 build.
>
> d
>

Within major versions (and thus far, there is only one of these), the coinstaller for a newer version will simply update the framework binaries for an older version.

There is a bug in this logic that applies to coinstallers in the beta WDK builds after RC1 (5600) and before RTM (6000). If these are installed, then the framework binaries will need to be removed before the RTM coinstaller can be used.

This bug has been identified as a test hole, and we have already taken steps (i.e., added new tests) to assure it never happens again. In our original test planning, these interim (between major milestones) releases weren’t supposed to occur, and (IMO) we didn’t get all the consequences when that changed. Again, IMO, the impact of this should be small, as these beta versions of the redistributables were not intended for end-customer installs.

Note that in the case of the OP, RC1 (5600) is being used, so installing a driver using the RTM coinstaller will be enough to fix this.

Thanks, it seems to work by removing the coinstallers. Now I can load the
symbols.

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Within major versions (and thus far, there is only one of these), the
coinstaller for a newer version will simply update the framework binaries
for an older version.

There is a bug in this logic that applies to coinstallers in the beta WDK
builds after RC1 (5600) and before RTM (6000). If these are installed, then
the framework binaries will need to be removed before the RTM coinstaller
can be used.

This bug has been identified as a test hole, and we have already taken steps
(i.e., added new tests) to assure it never happens again. In our original
test planning, these interim (between major milestones) releases weren’t
supposed to occur, and (IMO) we didn’t get all the consequences when that
changed. Again, IMO, the impact of this should be small, as these beta
versions of the redistributables were not intended for end-customer
installs.

Note that in the case of the OP, RC1 (5600) is being used, so installing a
driver using the RTM coinstaller will be enough to fix this.