hoonzang's CFPs: 25 new messages in 15 topics

microsoft.public.development.device.drivers
http://groups.google.com/group/microsoft.public.development.device.drivers?hl=en

microsoft.public.development.device.drivers@googlegroups.com

Today's topics:

==============================================================================
TOPIC: printing HardwareIDs
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/95fa3d09c626a39f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jun 22 2008 11:42 pm
From: krish

How can I print HardwareIDs? I understand they are MULTI_REG_SZ -
multiple strings each terminating with \0. Is there some function for
that.

Currently I wrote my own function as follows:

VOID DebugPrintStr (ULONG DebugPrintLevel,
PCWCHAR Buffer,
ULONG Length)
{
NTSTATUS status;
ULONG i; // index into the Buffer pointing to the begining of the
next string
ULONG j; // length of the current string

for (i = 0, j = 0; i < Length; i += (j + 1)) {
DbgPrintEx (DPFLTR_IHVDRIVER_ID, DebugPrintLevel, "%ws\n",
&Buffer[i]);
/* get the end of this string
*/
status = RtlStringCchLengthW (&Buffer[i],
Length +
1 - i, /* remaining MAX including the next '\0' */
&j); /*
length of upto (but not including) next '\0' */
}

}

And this is what I get? I'm not sure why I'm getting so many '?'.
Help. Thanks.

Intel-2920
???DisIntel-2920
Internal_IDE_Channel

??????? ??

??DisIntel-2920
J?????????????????????????????????????? ??????l-29???†??
?DisIntel-2920
?????????????????????????????????????? ??????l-29???†??
DisIntel-2920
????????????????????????????????????? ??????l-29???†??
isIntel-2920
???????????????????????????????????? ??????l-29???†??
sIntel-2920
??????????????????????????????????? ??????l-29???†??
Intel-2920
?????????????????????????????????? ??????l-29???†??
ntel-2920
????????????????????????????????? ??????l-29???†??
tel-2920
???????????????????????????????? ??????l-29???†??
el-2920
??????????????????????????????? ??????l-29???†??
?????????????????????????????? ??????l-29???†??
????????????????????????????? ??????l-29???†??
???????????????????????????? ??????l-29???†??
??????????????????????????? ??????l-29???†??
?????????????????????????? ??????l-29???†??
????????????????????????? ??????l-29???†??
????????????????????????
??????l-29???†??
???????????????????????
??????l-29???†??
??????????????????????
??????l-29???†??
?????????????????????
??????l-29???†??
????????????????????
??????l-29???†??

==============================================================================
TOPIC: @ALL - [SOLUTION],...
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/3fbcdbfbf47c8149?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 12:17 am
From: Uwe Sieber

Kelly wrote:
> This generally has to do with IPOD. See line 400:
> http://www.kellys-korner-xp.com/xp_tweaks.htm

This script removes upper and lower filters for
GUID_DEVCLASS_FLOPPYDISK. Any explanation why
this should affect non floppy devices?

Uwe

== 2 of 2 ==
Date: Mon, Jun 23 2008 12:19 am
From: Uwe Sieber

Uwe Sieber wrote:
> Kelly wrote:
>> This generally has to do with IPOD. See line 400:
>> http://www.kellys-korner-xp.com/xp_tweaks.htm
>
> This script removes upper and lower filters for
> GUID_DEVCLASS_FLOPPYDISK. Any explanation why
> this should affect non floppy devices?

Correction:
It removes upperfilters for GUID_DEVCLASS_FLOPPYDISK
and lowerfilters for GUID_DEVCLASS_DISKDRIVE.

Maybe the first was intended to be GUID_DEVCLASS_DISKDRIVE
too...

Uwe

==============================================================================
TOPIC: problem with NdisChainBufferAtFront
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/b3fba442f004d7a5?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 12:51 am
From: turambar

"Gianluca Varenni" wrote:

> Why are you playing with IRQLs?
>
> If you debug your crash, I'd bet it crashes when calling
> "KeLowerIrql(DISPATCH_LEVEL)". That dispatch routine is probably executing
> at PASSIVE_LEVEL, you are asking to lower the IRQL (which is non-sense) to
> an IRQL which is higher.
>
Hello,

Thanks but even if I don't call KeLowerIrql, the problem is the same. I used
this function because the error message is DRIVER_IRQL_NOT_LESS_OR_EQUAL.

I still don't know how to solve it.

== 2 of 2 ==
Date: Mon, Jun 23 2008 11:53 am
From: "Pavel A."

Meaning of DRIVER_IRQL_NOT_LESS_OR_EQUAL can be
also a page fault in invalid context - which is not actually related to
IRQLs.

Have a good look at your changes in the WDK sample.

--PA

"turambar <n-nospam@free.fr>"
<turambarnnospamfreefr@discussions.microsoft.com> wrote in message
news:E9FD80D7-9D5A-43CD-B5CA-65D3443F6915@microsoft.com...
>
>
> "Gianluca Varenni" wrote:
>
>> Why are you playing with IRQLs?
>>
>> If you debug your crash, I'd bet it crashes when calling
>> "KeLowerIrql(DISPATCH_LEVEL)". That dispatch routine is probably
>> executing
>> at PASSIVE_LEVEL, you are asking to lower the IRQL (which is non-sense)
>> to
>> an IRQL which is higher.
>>
> Hello,
>
> Thanks but even if I don't call KeLowerIrql, the problem is the same. I
> used
> this function because the error message is DRIVER_IRQL_NOT_LESS_OR_EQUAL.
>
> I still don't know how to solve it.
>
> TT

==============================================================================
TOPIC: Assert in pci.sys
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/1ce011e6b623c60d?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 7:10 am
From: Michael

Considering the assert is in pci.sys and not in my driver, how do I determine
what the bad offset is, and how to correct it?

"Pavel A." wrote:

> "Michael" <Michael@discussions.microsoft.com> wrote in message
> news:0A928337-ECE0-45B1-9334-EE251DF7D638@microsoft.com...
> > I have a PCIe x1 device that gets powered down in S3. When the system
> > resumes from S3, the memory space enable bit is not set in the config
> > space,
> > and the BARs are no longer configured correctly. I replaced pci.sys with
> > a
> > checked version, and turned on verbose logging. Pci.sys is asserting on
> > resume from S3. How can I determine the cause of this assert?
> >
> > *** Assertion failed: (Offset >= PCI_COMMON_HDR_LENGTH) && ((Offset & 0x3)
> > ==0)
>
> As you can see - some offset is either < PCI_COMMON_HDR_LENGTH
> (defined in wdm.h) or not aligned on 4 bytes. And this happens in
> PciReadDeviceCapability,
> so it might be the PM capability.
>
> --PA
>
>
>
>

== 2 of 2 ==
Date: Mon, Jun 23 2008 11:59 am
From: "Pavel A."

"Michael" <Michael@discussions.microsoft.com> wrote in message
news:AE807913-5750-4A5C-9C97-F5B56246A42A@microsoft.com...
> Considering the assert is in pci.sys and not in my driver, how do I
> determine
> what the bad offset is, and how to correct it?

My guess is this is offset of some PCI capability in the config space
of your card. How to find where exactly?
Try to disassemble near the place where pci.sys calls ASSERT,
maybe the bad value is left in local variables on stack.

--PA

> "Pavel A." wrote:
>
>> "Michael" <Michael@discussions.microsoft.com> wrote in message
>> news:0A928337-ECE0-45B1-9334-EE251DF7D638@microsoft.com...
>> > I have a PCIe x1 device that gets powered down in S3. When the system
>> > resumes from S3, the memory space enable bit is not set in the config
>> > space,
>> > and the BARs are no longer configured correctly. I replaced pci.sys
>> > with
>> > a
>> > checked version, and turned on verbose logging. Pci.sys is asserting
>> > on
>> > resume from S3. How can I determine the cause of this assert?
>> >
>> > *** Assertion failed: (Offset >= PCI_COMMON_HDR_LENGTH) && ((Offset &
>> > 0x3)
>> > ==0)
>>
>> As you can see - some offset is either < PCI_COMMON_HDR_LENGTH
>> (defined in wdm.h) or not aligned on 4 bytes. And this happens in
>> PciReadDeviceCapability,
>> so it might be the PM capability.
>>
>> --PA
>>
>>
>>
>>

==============================================================================
TOPIC: GDI Failure,...
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/b421e329831eaf89?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jun 23 2008 8:12 am
From: "Volodymyr M. Shcherbyna"

Well, I usually see picture like this, when some driver is leaking nonpaged
memory ...

--
V.
This posting is provided "AS IS" with no warranties, and confers no
rights.
"Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
news:eGF5DYP1IHA.4040@TK2MSFTNGP04.phx.gbl...
> Hi Ivan,
>
> reading you post again lead me to this question: If
> the limit is arround 10000 objects/handles, so why
> the os fails that way and just simply does not allow
> the creation of new object instances or notifies the
> user about something like "Out of GDI Objects".
> I mean this would be much better that rendering the
> complete UI useless,...or it should only fail the applications
> that requested the GDI Objects..
>
>>Gdi and User handle should be monitorable via perf-mon.
>>Their limit is around 10000 per process and 64000 per session
>
> Why is this limited? Wouldnt be a "Allocate until there is no more
> capacity" Strategy much better than limiting this.Trying to exceed
> that limit should just fail for the callers of the code that requested
> handles to objects,...
>
>
> Regards
>
> Kerem
>
> --
> -----------------------
> Beste Grüsse / Best regards / Votre bien devoue
> Kerem Gümrükcü
> Microsoft Live Space: http://kerem-g.spaces.live.com/
> Latest Open-Source Projects: http://entwicklung.junetz.de
> -----------------------
> "This reply is provided as is, without warranty express or implied."
> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> schrieb im
> Newsbeitrag news:6F36F36A-22BE-4F9E-99A8-D8B99AE99B0B@microsoft.com...
>> Gdi and User handle should be monitorable via perf-mon.
>> Their limit is around 10000 per process and 64000 per session.
>>
>> Desktop-Heap should be monitorable with a tool called dheapmon.
>> http://support.microsoft.com/kb/184802 should be a good reading.
>> For the general issue, this should also be a recomended reading.
>> http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx
>>
>> For the session space exhaustion, if you are on WinXp/Win2003-32-bit,
>> there are no magic tools that I'm aware of, short of debugging
>> the Mm structures in KD.
>> While I do not have a good idea why hibernation is triggering the issue,
>> I have debugged quite a few session space exhaustion, where either
>> the creation of a large bitmap was failing, or, the mere existence of
>> very large display driver was killing the contiguous space of session
>> space,
>> and, session space fragmentation was preventing all but small operations
>> from completing.
>>
>> --
>> --
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> Use of any included script samples are subject to the terms specified at
>> http://www.microsoft.com/info/cpyright.htm
>>
>>
>> "Ken Snyder" <mp5fmj@hotmail.com> wrote in message
>> news:%23jP0NoN1IHA.4004@TK2MSFTNGP03.phx.gbl...
>>> Hi Ivan,
>>>
>>>>The fact that you have a mirror driver would make me think of the 4th
>>>>one.
>>>
>>> at the Time this happened, the driver neither was started nor loaded
>>> in any way in the systems user/kernelspace, in fact it was just a binary
>>> located somewhere on the hard disk. The point is, that i did a call to
>>> SetSystemPowerState (hibernate,force), the system started to prepare
>>> for this and suddenly returned to that surface what you saw. No
>>> MessageBox,
>>> schowing any "Driver did not allow to set state xyz" or something like
>>> that.
>>> But why and what has happened that made any characters and any sort of
>>> drawing text gone, especially the console subsystem. What happened
>>> internally there? What is the Limit of USER/GDI/DESKTOP/SESSION
>>> Objects/Handles? I do have lots of physical memory (i mean if not there
>>> is
>>> virtual space, no matter how much physical you have!) But i do not have
>>> lots of paging access while working, anyway, whats the Limit of these
>>> objects
>>> and on what does this depend,...and what do i have to take care/measure
>>> to avoid such situations,...i guess there is no indicator for this,..am
>>> i
>>> right?
>>>
>>>
>>> Regards
>>>
>>> Kerem
>>>
>>> --
>>> --
>>> -----------------------
>>> Beste Grüsse / Best regards / Votre bien devoue
>>> Kerem Gümrükcü
>>> Microsoft Live Space: http://kerem-g.spaces.live.com/
>>> Latest Open-Source Projects: http://entwicklung.junetz.de
>>> -----------------------
>>> "This reply is provided as is, without warranty express or implied."
>>>
>>> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> schrieb im
>>> Newsbeitrag news:545DB2A6-61E4-484D-BCB0-93980F1F4822@microsoft.com...
>>>> The images shown would make me think of GDI handle exhaustion,
>>>> USER handle exhaustion, Desktop-Heap exhaustion, or, Session-Space
>>>> exhausion.
>>>> The fact that you have a mirror driver would make me think of the 4th
>>>> one.
>>>>
>>>> --
>>>> --
>>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>>> Use of any included script samples are subject to the terms specified
>>>> at
>>>> http://www.microsoft.com/info/cpyright.htm
>>>>
>>>>
>>>> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
>>>> news:OwNNLML1IHA.4572@TK2MSFTNGP03.phx.gbl...
>>>> > Hi Alexander,
>>>> >
>>>> >>1. Check your system memory for stability (good memory test, not just
>>>> >>POST)
>>>> >
>>>> > My recommendation for everybody:
>>>> > http://www.memtest.org/
>>>> >
>>>> > I checked memory even yesterday,..really! No Problems,...
>>>> >
>>>> >>2. That could be your video driver misbehaving. Or some crapware
>>>> >>hooked
>>> to
>>>> >>your video drover (remote access?)
>>>> >
>>>> > The only video driver attached to the system except
>>>> > the primary video driver is UltraVNC Video Driver
>>>> > and there was never ever a problem with it at least
>>>> > on my system. Here is some Version info:
>>>> >
>>>> > C:\Programme\verinfo>verinfo C:\WINDOWS\system32\drivers\vncdrv.sys
>>>> >
>>>> > File Version Info for:
>>>> > "C:\WINDOWS\system32\drivers\vncdrv.sys"
>>>> >
>>>> > [FileName]
>>>> > -- C:\WINDOWS\system32\drivers\vncdrv.sys --
>>>> > [Language]
>>>> > -- Sprachneutral --
>>>> > [Comments]
>>>> > -- "No Information Available" --
>>>> > [CompanyName]
>>>> > -- RDV Soft --
>>>> > [FileDescription]
>>>> > -- Ultravnc Mirror Driver --
>>>> > [FileVersion]
>>>> > -- 1.00.17 --
>>>> > [InternalName]
>>>> > -- vncdrv.sys --
>>>> > [LegalCopyright]
>>>> > -- RDV Soft --
>>>> > [LegalTrademarks]
>>>> > -- "No Information Available" --
>>>> > [OriginalFilename]
>>>> > -- vncdrv.sys --
>>>> > [ProductName]
>>>> > -- UltraVnc Mirror Driver --
>>>> > [ProductVersion]
>>>> > -- 1.00.17 --
>>>> > [PrivateBuild]
>>>> > -- "No Information Available" --
>>>> > [SpecialBuild]
>>>> > -- "No Information Available" --
>>>> > [Checksums]
>>>> > -- Header Sum: 65670 --
>>>> > -- Computed Sum: 65670 --
>>>> > [ImageExtraInfo]
>>>> > -- Image Characteristics: 270 --
>>>> > -- Machine: 332 --
>>>> > -- Subsystem: 1 --
>>>> > -- Major Linker Version: 7 --
>>>> > -- Minor Linker Version: 10 --
>>>> > -- Minor Image Version: 5 --
>>>> > -- Minor Image Version: 0 --
>>>> > -- Major Operating System Version: 5 --
>>>> > -- Minor Operating System Version: 0 --
>>>> > -- Major Subsystem Version: 5 --
>>>> > -- Minor Subsystem Version: 0 --
>>>> > -- Image Magic: 267 --
>>>> > -- Image Checksum: 65670 --
>>>> > -- Image Dll Characteristics: 1024 --
>>>> >
>>>> >
>>>> > Even it was not loaded and/or activated while this happened,...
>>>> >
>>>> > Regards
>>>> >
>>>> > Kerem
>>>> >
>>>> > --
>>>> > -----------------------
>>>> > Beste Grüsse / Best regards / Votre bien devoue
>>>> > Kerem Gümrükcü
>>>> > Microsoft Live Space: http://kerem-g.spaces.live.com/
>>>> > Latest Open-Source Projects: http://entwicklung.junetz.de
>>>> > -----------------------
>>>> > "This reply is provided as is, without warranty express or implied."
>>>> > "Alexander Grigoriev" <alegr@earthlink.net> schrieb im Newsbeitrag
>>>> > news:uAFzeFL1IHA.1628@TK2MSFTNGP03.phx.gbl...
>>>> >> 1. Check your system memory for stability (good memory test, not
>>>> >> just
>>>> >> POST)
>>>> >> 2. That could be your video driver misbehaving. Or some crapware
>>>> >> hooked
>>>> >> to your video drover (remote access?)
>>>> >>
>>>> >> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
>>>> >> news:%23A%23wT$J1IHA.4164@TK2MSFTNGP03.phx.gbl...
>>>> >>> Hi,
>>>> >>>
>>>> >>> this speaks for itself:
>>>> >>>
>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr1.jpg
>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr2.jpg
>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr3.jpg
>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr4.jpg
>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr5.jpg
>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr6.jpg
>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr7.jpg
>>>> >>>
>>>> >>> How this happened: I wanted to send System to Hbernation Mode,
>>>> >>> but it was not able to enter this state: No Error Log Entries, no
>>>> >>> Messages, it just turned from "Preparing for Hibernation,..." to
>>>> >>> this Window. Interessting is that you can see in a Screenshot that
>>>> >>> everything is rendered false except the disabled MenuItems on
>>>> >>> Menus. Why only disabled items are drawn correctly. An why
>>>> >>> can the content from Internet Explorer be drawn correctly?
>>>> >>> Every Application started after this fault has totally destroyed
>>>> >>> Character repesentation and Consoles write their buffers also
>>>> >>> false and randomly as you can see. I had to restart the complete
>>>> >>> System to get a usefull state. If i wouldn't be that familliar with
>>>> >>> the OS and MS Paint i couldnt make these screeenshots and
>>>> >>> save them, since you can read nothing on any window or menu
>>>> >>> items,...
>>>> >>>
>>>> >>> Oh yes, why will the content from FreeMath rendered successfully
>>>> >>> and other apps not?
>>>> >>>
>>>> >>> Its OT but maybe someone is interessted in it and also can expplain
>>>> >>> me what and why this happens,...OS is SP3 WinXPPro, you propably
>>>> >>> already figured this out from the Screenshots,..
>>>> >>>
>>>> >>> Regards
>>>> >>>
>>>> >>> Kerem
>>>> >>>
>>>> >>> --
>>>> >>> -----------------------
>>>> >>> Beste Grüsse / Best regards / Votre bien devoue
>>>> >>> Kerem Gümrükcü
>>>> >>> Microsoft Live Space: http://kerem-g.spaces.live.com/
>>>> >>> Latest Open-Source Projects: http://entwicklung.junetz.de
>>>> >>> -----------------------
>>>> >>> "This reply is provided as is, without warranty express or
>>>> >>> implied."
>>>> >>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>

== 2 of 3 ==
Date: Mon, Jun 23 2008 8:40 am
From: Kerem Gümrükcü

Hi V.

i dont know what is hapenning to my system the last days,
but it really freaks out. Ten minutes ago, i got this while
resuking from hibernation:

KERNEL_STACK_INPAGE_ERROR (77)
The requested page of kernel data could not be read in. Caused by
bad block in paging file or disk controller error.
In the case when the first arguments is 0 or 1, the stack signature
in the kernel stack was not found. Again, bad hardware.
An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates
the data could not be read from the disk due to a bad
block. Upon reboot autocheck will run and attempt to map out the bad
sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
file is on a SCSI disk device, then the cabling and termination should be
checked. See the knowledge base article on SCSI termination.
Arguments:
Arg1: 00000001, (page was retrieved from disk)
Arg2: 00000000, value found in stack where signature should be
Arg3: 00000000, 0
Arg4: f2e6b95c, address of signature on kernel stack
MODULE_NAME: nt

FAULTING_MODULE: 804d7000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 48025eab

ERROR_CODE: (NTSTATUS) 0x1 - STATUS_WAIT_1

BUGCHECK_STR: 0x77_1

DEFAULT_BUCKET_ID: WRONG_SYMBOLS

LAST_CONTROL_TRANSFER: from 80521007 to 8053380e

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be
wrong.
f7914d68 80521007 00000077 00000001 00000000 nt!KeBugCheckEx+0x1b
f7914d8c 804e6b41 003dbda8 00000000 86bbf838 nt!IoSetFileOrigin+0x9043
f7914da4 804e6b24 863dbe08 8057aeff 00000000 nt!KeResetEvent+0x256
f7914ddc 804f88ea 804e6aa0 00000000 00000000 nt!KeResetEvent+0x239
00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107

Now i think, its time for a chkdsk on the system.

Regards

Kerem

--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."
"Volodymyr M. Shcherbyna" <v_scherbina@online.mvps.org> schrieb im
Newsbeitrag news:OZAkHOU1IHA.2292@TK2MSFTNGP03.phx.gbl...
> Well, I usually see picture like this, when some driver is leaking
> nonpaged memory ...
>
> --
> V.
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
> news:eGF5DYP1IHA.4040@TK2MSFTNGP04.phx.gbl...
>> Hi Ivan,
>>
>> reading you post again lead me to this question: If
>> the limit is arround 10000 objects/handles, so why
>> the os fails that way and just simply does not allow
>> the creation of new object instances or notifies the
>> user about something like "Out of GDI Objects".
>> I mean this would be much better that rendering the
>> complete UI useless,...or it should only fail the applications
>> that requested the GDI Objects..
>>
>>>Gdi and User handle should be monitorable via perf-mon.
>>>Their limit is around 10000 per process and 64000 per session
>>
>> Why is this limited? Wouldnt be a "Allocate until there is no more
>> capacity" Strategy much better than limiting this.Trying to exceed
>> that limit should just fail for the callers of the code that requested
>> handles to objects,...
>>
>>
>> Regards
>>
>> Kerem
>>
>> --
>> -----------------------
>> Beste Grüsse / Best regards / Votre bien devoue
>> Kerem Gümrükcü
>> Microsoft Live Space: http://kerem-g.spaces.live.com/
>> Latest Open-Source Projects: http://entwicklung.junetz.de
>> -----------------------
>> "This reply is provided as is, without warranty express or implied."
>> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> schrieb im
>> Newsbeitrag news:6F36F36A-22BE-4F9E-99A8-D8B99AE99B0B@microsoft.com...
>>> Gdi and User handle should be monitorable via perf-mon.
>>> Their limit is around 10000 per process and 64000 per session.
>>>
>>> Desktop-Heap should be monitorable with a tool called dheapmon.
>>> http://support.microsoft.com/kb/184802 should be a good reading.
>>> For the general issue, this should also be a recomended reading.
>>> http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx
>>>
>>> For the session space exhaustion, if you are on WinXp/Win2003-32-bit,
>>> there are no magic tools that I'm aware of, short of debugging
>>> the Mm structures in KD.
>>> While I do not have a good idea why hibernation is triggering the issue,
>>> I have debugged quite a few session space exhaustion, where either
>>> the creation of a large bitmap was failing, or, the mere existence of
>>> very large display driver was killing the contiguous space of session
>>> space,
>>> and, session space fragmentation was preventing all but small operations
>>> from completing.
>>>
>>> --
>>> --
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>> Use of any included script samples are subject to the terms specified at
>>> http://www.microsoft.com/info/cpyright.htm
>>>
>>>
>>> "Ken Snyder" <mp5fmj@hotmail.com> wrote in message
>>> news:%23jP0NoN1IHA.4004@TK2MSFTNGP03.phx.gbl...
>>>> Hi Ivan,
>>>>
>>>>>The fact that you have a mirror driver would make me think of the 4th
>>>>>one.
>>>>
>>>> at the Time this happened, the driver neither was started nor loaded
>>>> in any way in the systems user/kernelspace, in fact it was just a
>>>> binary
>>>> located somewhere on the hard disk. The point is, that i did a call to
>>>> SetSystemPowerState (hibernate,force), the system started to prepare
>>>> for this and suddenly returned to that surface what you saw. No
>>>> MessageBox,
>>>> schowing any "Driver did not allow to set state xyz" or something like
>>>> that.
>>>> But why and what has happened that made any characters and any sort of
>>>> drawing text gone, especially the console subsystem. What happened
>>>> internally there? What is the Limit of USER/GDI/DESKTOP/SESSION
>>>> Objects/Handles? I do have lots of physical memory (i mean if not there
>>>> is
>>>> virtual space, no matter how much physical you have!) But i do not have
>>>> lots of paging access while working, anyway, whats the Limit of these
>>>> objects
>>>> and on what does this depend,...and what do i have to take care/measure
>>>> to avoid such situations,...i guess there is no indicator for this,..am
>>>> i
>>>> right?
>>>>
>>>>
>>>> Regards
>>>>
>>>> Kerem
>>>>
>>>> --
>>>> --
>>>> -----------------------
>>>> Beste Grüsse / Best regards / Votre bien devoue
>>>> Kerem Gümrükcü
>>>> Microsoft Live Space: http://kerem-g.spaces.live.com/
>>>> Latest Open-Source Projects: http://entwicklung.junetz.de
>>>> -----------------------
>>>> "This reply is provided as is, without warranty express or implied."
>>>>
>>>> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> schrieb im
>>>> Newsbeitrag news:545DB2A6-61E4-484D-BCB0-93980F1F4822@microsoft.com...
>>>>> The images shown would make me think of GDI handle exhaustion,
>>>>> USER handle exhaustion, Desktop-Heap exhaustion, or, Session-Space
>>>>> exhausion.
>>>>> The fact that you have a mirror driver would make me think of the 4th
>>>>> one.
>>>>>
>>>>> --
>>>>> --
>>>>> This posting is provided "AS IS" with no warranties, and confers no
>>>> rights.
>>>>> Use of any included script samples are subject to the terms specified
>>>>> at
>>>>> http://www.microsoft.com/info/cpyright.htm
>>>>>
>>>>>
>>>>> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
>>>>> news:OwNNLML1IHA.4572@TK2MSFTNGP03.phx.gbl...
>>>>> > Hi Alexander,
>>>>> >
>>>>> >>1. Check your system memory for stability (good memory test, not
>>>>> >>just
>>>>> >>POST)
>>>>> >
>>>>> > My recommendation for everybody:
>>>>> > http://www.memtest.org/
>>>>> >
>>>>> > I checked memory even yesterday,..really! No Problems,...
>>>>> >
>>>>> >>2. That could be your video driver misbehaving. Or some crapware
>>>>> >>hooked
>>>> to
>>>>> >>your video drover (remote access?)
>>>>> >
>>>>> > The only video driver attached to the system except
>>>>> > the primary video driver is UltraVNC Video Driver
>>>>> > and there was never ever a problem with it at least
>>>>> > on my system. Here is some Version info:
>>>>> >
>>>>> > C:\Programme\verinfo>verinfo C:\WINDOWS\system32\drivers\vncdrv.sys
>>>>> >
>>>>> > File Version Info for:
>>>>> > "C:\WINDOWS\system32\drivers\vncdrv.sys"
>>>>> >
>>>>> > [FileName]
>>>>> > -- C:\WINDOWS\system32\drivers\vncdrv.sys --
>>>>> > [Language]
>>>>> > -- Sprachneutral --
>>>>> > [Comments]
>>>>> > -- "No Information Available" --
>>>>> > [CompanyName]
>>>>> > -- RDV Soft --
>>>>> > [FileDescription]
>>>>> > -- Ultravnc Mirror Driver --
>>>>> > [FileVersion]
>>>>> > -- 1.00.17 --
>>>>> > [InternalName]
>>>>> > -- vncdrv.sys --
>>>>> > [LegalCopyright]
>>>>> > -- RDV Soft --
>>>>> > [LegalTrademarks]
>>>>> > -- "No Information Available" --
>>>>> > [OriginalFilename]
>>>>> > -- vncdrv.sys --
>>>>> > [ProductName]
>>>>> > -- UltraVnc Mirror Driver --
>>>>> > [ProductVersion]
>>>>> > -- 1.00.17 --
>>>>> > [PrivateBuild]
>>>>> > -- "No Information Available" --
>>>>> > [SpecialBuild]
>>>>> > -- "No Information Available" --
>>>>> > [Checksums]
>>>>> > -- Header Sum: 65670 --
>>>>> > -- Computed Sum: 65670 --
>>>>> > [ImageExtraInfo]
>>>>> > -- Image Characteristics: 270 --
>>>>> > -- Machine: 332 --
>>>>> > -- Subsystem: 1 --
>>>>> > -- Major Linker Version: 7 --
>>>>> > -- Minor Linker Version: 10 --
>>>>> > -- Minor Image Version: 5 --
>>>>> > -- Minor Image Version: 0 --
>>>>> > -- Major Operating System Version: 5 --
>>>>> > -- Minor Operating System Version: 0 --
>>>>> > -- Major Subsystem Version: 5 --
>>>>> > -- Minor Subsystem Version: 0 --
>>>>> > -- Image Magic: 267 --
>>>>> > -- Image Checksum: 65670 --
>>>>> > -- Image Dll Characteristics: 1024 --
>>>>> >
>>>>> >
>>>>> > Even it was not loaded and/or activated while this happened,...
>>>>> >
>>>>> > Regards
>>>>> >
>>>>> > Kerem
>>>>> >
>>>>> > --
>>>>> > -----------------------
>>>>> > Beste Grüsse / Best regards / Votre bien devoue
>>>>> > Kerem Gümrükcü
>>>>> > Microsoft Live Space: http://kerem-g.spaces.live.com/
>>>>> > Latest Open-Source Projects: http://entwicklung.junetz.de
>>>>> > -----------------------
>>>>> > "This reply is provided as is, without warranty express or implied."
>>>>> > "Alexander Grigoriev" <alegr@earthlink.net> schrieb im Newsbeitrag
>>>>> > news:uAFzeFL1IHA.1628@TK2MSFTNGP03.phx.gbl...
>>>>> >> 1. Check your system memory for stability (good memory test, not
>>>>> >> just
>>>>> >> POST)
>>>>> >> 2. That could be your video driver misbehaving. Or some crapware
>>>>> >> hooked
>>>>> >> to your video drover (remote access?)
>>>>> >>
>>>>> >> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
>>>>> >> news:%23A%23wT$J1IHA.4164@TK2MSFTNGP03.phx.gbl...
>>>>> >>> Hi,
>>>>> >>>
>>>>> >>> this speaks for itself:
>>>>> >>>
>>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr1.jpg
>>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr2.jpg
>>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr3.jpg
>>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr4.jpg
>>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr5.jpg
>>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr6.jpg
>>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr7.jpg
>>>>> >>>
>>>>> >>> How this happened: I wanted to send System to Hbernation Mode,
>>>>> >>> but it was not able to enter this state: No Error Log Entries, no
>>>>> >>> Messages, it just turned from "Preparing for Hibernation,..." to
>>>>> >>> this Window. Interessting is that you can see in a Screenshot that
>>>>> >>> everything is rendered false except the disabled MenuItems on
>>>>> >>> Menus. Why only disabled items are drawn correctly. An why
>>>>> >>> can the content from Internet Explorer be drawn correctly?
>>>>> >>> Every Application started after this fault has totally destroyed
>>>>> >>> Character repesentation and Consoles write their buffers also
>>>>> >>> false and randomly as you can see. I had to restart the complete
>>>>> >>> System to get a usefull state. If i wouldn't be that familliar
>>>>> >>> with
>>>>> >>> the OS and MS Paint i couldnt make these screeenshots and
>>>>> >>> save them, since you can read nothing on any window or menu
>>>>> >>> items,...
>>>>> >>>
>>>>> >>> Oh yes, why will the content from FreeMath rendered successfully
>>>>> >>> and other apps not?
>>>>> >>>
>>>>> >>> Its OT but maybe someone is interessted in it and also can
>>>>> >>> expplain
>>>>> >>> me what and why this happens,...OS is SP3 WinXPPro, you propably
>>>>> >>> already figured this out from the Screenshots,..
>>>>> >>>
>>>>> >>> Regards
>>>>> >>>
>>>>> >>> Kerem
>>>>> >>>
>>>>> >>> --
>>>>> >>> -----------------------
>>>>> >>> Beste Grüsse / Best regards / Votre bien devoue
>>>>> >>> Kerem Gümrükcü
>>>>> >>> Microsoft Live Space: http://kerem-g.spaces.live.com/
>>>>> >>> Latest Open-Source Projects: http://entwicklung.junetz.de
>>>>> >>> -----------------------
>>>>> >>> "This reply is provided as is, without warranty express or
>>>>> >>> implied."
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
>

== 3 of 3 ==
Date: Mon, Jun 23 2008 9:37 am
From: "Ken Snyder"

Hi,

>Now i think, its time for a chkdsk on the system.

it looks like it was a corrupted FS,...
chkdsk showed me some errors found
on the disk,...

Dude, what a corrupted fs is causing trouble,...

Regards

Kerem

--
--
-----------------------
Beste Grüsse / Best regards / Votre bien devoue
Kerem Gümrükcü
Microsoft Live Space: http://kerem-g.spaces.live.com/
Latest Open-Source Projects: http://entwicklung.junetz.de
-----------------------
"This reply is provided as is, without warranty express or implied."

"Kerem Gümrükcü" <kareem114@hotmail.com> schrieb im Newsbeitrag
news:Odf%239dU1IHA.5472@TK2MSFTNGP06.phx.gbl...
> Hi V.
>
> i dont know what is hapenning to my system the last days,
> but it really freaks out. Ten minutes ago, i got this while
> resuking from hibernation:
>
> KERNEL_STACK_INPAGE_ERROR (77)
> The requested page of kernel data could not be read in. Caused by
> bad block in paging file or disk controller error.
> In the case when the first arguments is 0 or 1, the stack signature
> in the kernel stack was not found. Again, bad hardware.
> An I/O status of c000009c (STATUS_DEVICE_DATA_ERROR) or
> C000016AL (STATUS_DISK_OPERATION_FAILED) normally indicates
> the data could not be read from the disk due to a bad
> block. Upon reboot autocheck will run and attempt to map out the bad
> sector. If the status is C0000185 (STATUS_IO_DEVICE_ERROR) and the paging
> file is on a SCSI disk device, then the cabling and termination should be
> checked. See the knowledge base article on SCSI termination.
> Arguments:
> Arg1: 00000001, (page was retrieved from disk)
> Arg2: 00000000, value found in stack where signature should be
> Arg3: 00000000, 0
> Arg4: f2e6b95c, address of signature on kernel stack
> MODULE_NAME: nt
>
> FAULTING_MODULE: 804d7000 nt
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 48025eab
>
> ERROR_CODE: (NTSTATUS) 0x1 - STATUS_WAIT_1
>
> BUGCHECK_STR: 0x77_1
>
> DEFAULT_BUCKET_ID: WRONG_SYMBOLS
>
> LAST_CONTROL_TRANSFER: from 80521007 to 8053380e
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> f7914d68 80521007 00000077 00000001 00000000 nt!KeBugCheckEx+0x1b
> f7914d8c 804e6b41 003dbda8 00000000 86bbf838 nt!IoSetFileOrigin+0x9043
> f7914da4 804e6b24 863dbe08 8057aeff 00000000 nt!KeResetEvent+0x256
> f7914ddc 804f88ea 804e6aa0 00000000 00000000 nt!KeResetEvent+0x239
> 00000000 00000000 00000000 00000000 00000000 nt!KeInitializeTimer+0x107
>
>
> Now i think, its time for a chkdsk on the system.
>
> Regards
>
> Kerem
>
>
> --
> -----------------------
> Beste Grüsse / Best regards / Votre bien devoue
> Kerem Gümrükcü
> Microsoft Live Space: http://kerem-g.spaces.live.com/
> Latest Open-Source Projects: http://entwicklung.junetz.de
> -----------------------
> "This reply is provided as is, without warranty express or implied."
> "Volodymyr M. Shcherbyna" <v_scherbina@online.mvps.org> schrieb im
> Newsbeitrag news:OZAkHOU1IHA.2292@TK2MSFTNGP03.phx.gbl...
> > Well, I usually see picture like this, when some driver is leaking
> > nonpaged memory ...
> >
> > --
> > V.
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
> > news:eGF5DYP1IHA.4040@TK2MSFTNGP04.phx.gbl...
> >> Hi Ivan,
> >>
> >> reading you post again lead me to this question: If
> >> the limit is arround 10000 objects/handles, so why
> >> the os fails that way and just simply does not allow
> >> the creation of new object instances or notifies the
> >> user about something like "Out of GDI Objects".
> >> I mean this would be much better that rendering the
> >> complete UI useless,...or it should only fail the applications
> >> that requested the GDI Objects..
> >>
> >>>Gdi and User handle should be monitorable via perf-mon.
> >>>Their limit is around 10000 per process and 64000 per session
> >>
> >> Why is this limited? Wouldnt be a "Allocate until there is no more
> >> capacity" Strategy much better than limiting this.Trying to exceed
> >> that limit should just fail for the callers of the code that requested
> >> handles to objects,...
> >>
> >>
> >> Regards
> >>
> >> Kerem
> >>
> >> --
> >> -----------------------
> >> Beste Grüsse / Best regards / Votre bien devoue
> >> Kerem Gümrükcü
> >> Microsoft Live Space: http://kerem-g.spaces.live.com/
> >> Latest Open-Source Projects: http://entwicklung.junetz.de
> >> -----------------------
> >> "This reply is provided as is, without warranty express or implied."
> >> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> schrieb im
> >> Newsbeitrag news:6F36F36A-22BE-4F9E-99A8-D8B99AE99B0B@microsoft.com...
> >>> Gdi and User handle should be monitorable via perf-mon.
> >>> Their limit is around 10000 per process and 64000 per session.
> >>>
> >>> Desktop-Heap should be monitorable with a tool called dheapmon.
> >>> http://support.microsoft.com/kb/184802 should be a good reading.
> >>> For the general issue, this should also be a recomended reading.
> >>>
http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx
> >>>
> >>> For the session space exhaustion, if you are on WinXp/Win2003-32-bit,
> >>> there are no magic tools that I'm aware of, short of debugging
> >>> the Mm structures in KD.
> >>> While I do not have a good idea why hibernation is triggering the
issue,
> >>> I have debugged quite a few session space exhaustion, where either
> >>> the creation of a large bitmap was failing, or, the mere existence of
> >>> very large display driver was killing the contiguous space of session
> >>> space,
> >>> and, session space fragmentation was preventing all but small
operations
> >>> from completing.
> >>>
> >>> --
> >>> --
> >>> This posting is provided "AS IS" with no warranties, and confers no
> >>> rights.
> >>> Use of any included script samples are subject to the terms specified
at
> >>> http://www.microsoft.com/info/cpyright.htm
> >>>
> >>>
> >>> "Ken Snyder" <mp5fmj@hotmail.com> wrote in message
> >>> news:%23jP0NoN1IHA.4004@TK2MSFTNGP03.phx.gbl...
> >>>> Hi Ivan,
> >>>>
> >>>>>The fact that you have a mirror driver would make me think of the 4th
> >>>>>one.
> >>>>
> >>>> at the Time this happened, the driver neither was started nor loaded
> >>>> in any way in the systems user/kernelspace, in fact it was just a
> >>>> binary
> >>>> located somewhere on the hard disk. The point is, that i did a call
to
> >>>> SetSystemPowerState (hibernate,force), the system started to prepare
> >>>> for this and suddenly returned to that surface what you saw. No
> >>>> MessageBox,
> >>>> schowing any "Driver did not allow to set state xyz" or something
like
> >>>> that.
> >>>> But why and what has happened that made any characters and any sort
of
> >>>> drawing text gone, especially the console subsystem. What happened
> >>>> internally there? What is the Limit of USER/GDI/DESKTOP/SESSION
> >>>> Objects/Handles? I do have lots of physical memory (i mean if not
there
> >>>> is
> >>>> virtual space, no matter how much physical you have!) But i do not
have
> >>>> lots of paging access while working, anyway, whats the Limit of these
> >>>> objects
> >>>> and on what does this depend,...and what do i have to take
care/measure
> >>>> to avoid such situations,...i guess there is no indicator for
this,..am
> >>>> i
> >>>> right?
> >>>>
> >>>>
> >>>> Regards
> >>>>
> >>>> Kerem
> >>>>
> >>>> --
> >>>> --
> >>>> -----------------------
> >>>> Beste Grüsse / Best regards / Votre bien devoue
> >>>> Kerem Gümrükcü
> >>>> Microsoft Live Space: http://kerem-g.spaces.live.com/
> >>>> Latest Open-Source Projects: http://entwicklung.junetz.de
> >>>> -----------------------
> >>>> "This reply is provided as is, without warranty express or implied."
> >>>>
> >>>> "Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> schrieb im
> >>>> Newsbeitrag
news:545DB2A6-61E4-484D-BCB0-93980F1F4822@microsoft.com...
> >>>>> The images shown would make me think of GDI handle exhaustion,
> >>>>> USER handle exhaustion, Desktop-Heap exhaustion, or, Session-Space
> >>>>> exhausion.
> >>>>> The fact that you have a mirror driver would make me think of the
4th
> >>>>> one.
> >>>>>
> >>>>> --
> >>>>> --
> >>>>> This posting is provided "AS IS" with no warranties, and confers no
> >>>> rights.
> >>>>> Use of any included script samples are subject to the terms
specified
> >>>>> at
> >>>>> http://www.microsoft.com/info/cpyright.htm
> >>>>>
> >>>>>
> >>>>> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
> >>>>> news:OwNNLML1IHA.4572@TK2MSFTNGP03.phx.gbl...
> >>>>> > Hi Alexander,
> >>>>> >
> >>>>> >>1. Check your system memory for stability (good memory test, not
> >>>>> >>just
> >>>>> >>POST)
> >>>>> >
> >>>>> > My recommendation for everybody:
> >>>>> > http://www.memtest.org/
> >>>>> >
> >>>>> > I checked memory even yesterday,..really! No Problems,...
> >>>>> >
> >>>>> >>2. That could be your video driver misbehaving. Or some crapware
> >>>>> >>hooked
> >>>> to
> >>>>> >>your video drover (remote access?)
> >>>>> >
> >>>>> > The only video driver attached to the system except
> >>>>> > the primary video driver is UltraVNC Video Driver
> >>>>> > and there was never ever a problem with it at least
> >>>>> > on my system. Here is some Version info:
> >>>>> >
> >>>>> > C:\Programme\verinfo>verinfo
C:\WINDOWS\system32\drivers\vncdrv.sys
> >>>>> >
> >>>>> > File Version Info for:
> >>>>> > "C:\WINDOWS\system32\drivers\vncdrv.sys"
> >>>>> >
> >>>>> > [FileName]
> >>>>> > -- C:\WINDOWS\system32\drivers\vncdrv.sys --
> >>>>> > [Language]
> >>>>> > -- Sprachneutral --
> >>>>> > [Comments]
> >>>>> > -- "No Information Available" --
> >>>>> > [CompanyName]
> >>>>> > -- RDV Soft --
> >>>>> > [FileDescription]
> >>>>> > -- Ultravnc Mirror Driver --
> >>>>> > [FileVersion]
> >>>>> > -- 1.00.17 --
> >>>>> > [InternalName]
> >>>>> > -- vncdrv.sys --
> >>>>> > [LegalCopyright]
> >>>>> > -- RDV Soft --
> >>>>> > [LegalTrademarks]
> >>>>> > -- "No Information Available" --
> >>>>> > [OriginalFilename]
> >>>>> > -- vncdrv.sys --
> >>>>> > [ProductName]
> >>>>> > -- UltraVnc Mirror Driver --
> >>>>> > [ProductVersion]
> >>>>> > -- 1.00.17 --
> >>>>> > [PrivateBuild]
> >>>>> > -- "No Information Available" --
> >>>>> > [SpecialBuild]
> >>>>> > -- "No Information Available" --
> >>>>> > [Checksums]
> >>>>> > -- Header Sum: 65670 --
> >>>>> > -- Computed Sum: 65670 --
> >>>>> > [ImageExtraInfo]
> >>>>> > -- Image Characteristics: 270 --
> >>>>> > -- Machine: 332 --
> >>>>> > -- Subsystem: 1 --
> >>>>> > -- Major Linker Version: 7 --
> >>>>> > -- Minor Linker Version: 10 --
> >>>>> > -- Minor Image Version: 5 --
> >>>>> > -- Minor Image Version: 0 --
> >>>>> > -- Major Operating System Version: 5 --
> >>>>> > -- Minor Operating System Version: 0 --
> >>>>> > -- Major Subsystem Version: 5 --
> >>>>> > -- Minor Subsystem Version: 0 --
> >>>>> > -- Image Magic: 267 --
> >>>>> > -- Image Checksum: 65670 --
> >>>>> > -- Image Dll Characteristics: 1024 --
> >>>>> >
> >>>>> >
> >>>>> > Even it was not loaded and/or activated while this happened,...
> >>>>> >
> >>>>> > Regards
> >>>>> >
> >>>>> > Kerem
> >>>>> >
> >>>>> > --
> >>>>> > -----------------------
> >>>>> > Beste Grüsse / Best regards / Votre bien devoue
> >>>>> > Kerem Gümrükcü
> >>>>> > Microsoft Live Space: http://kerem-g.spaces.live.com/
> >>>>> > Latest Open-Source Projects: http://entwicklung.junetz.de
> >>>>> > -----------------------
> >>>>> > "This reply is provided as is, without warranty express or
implied."
> >>>>> > "Alexander Grigoriev" <alegr@earthlink.net> schrieb im Newsbeitrag
> >>>>> > news:uAFzeFL1IHA.1628@TK2MSFTNGP03.phx.gbl...
> >>>>> >> 1. Check your system memory for stability (good memory test, not
> >>>>> >> just
> >>>>> >> POST)
> >>>>> >> 2. That could be your video driver misbehaving. Or some crapware
> >>>>> >> hooked
> >>>>> >> to your video drover (remote access?)
> >>>>> >>
> >>>>> >> "Kerem Gümrükcü" <kareem114@hotmail.com> wrote in message
> >>>>> >> news:%23A%23wT$J1IHA.4164@TK2MSFTNGP03.phx.gbl...
> >>>>> >>> Hi,
> >>>>> >>>
> >>>>> >>> this speaks for itself:
> >>>>> >>>
> >>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr1.jpg
> >>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr2.jpg
> >>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr3.jpg
> >>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr4.jpg
> >>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr5.jpg
> >>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr6.jpg
> >>>>> >>> http://www.pro-it-education.de/staff/keremg/misc/gdierr7.jpg
> >>>>> >>>
> >>>>> >>> How this happened: I wanted to send System to Hbernation Mode,
> >>>>> >>> but it was not able to enter this state: No Error Log Entries,
no
> >>>>> >>> Messages, it just turned from "Preparing for Hibernation,..."
to
> >>>>> >>> this Window. Interessting is that you can see in a Screenshot
that
> >>>>> >>> everything is rendered false except the disabled MenuItems on
> >>>>> >>> Menus. Why only disabled items are drawn correctly. An why
> >>>>> >>> can the content from Internet Explorer be drawn correctly?
> >>>>> >>> Every Application started after this fault has totally destroyed
> >>>>> >>> Character repesentation and Consoles write their buffers also
> >>>>> >>> false and randomly as you can see. I had to restart the complete
> >>>>> >>> System to get a usefull state. If i wouldn't be that familliar
> >>>>> >>> with
> >>>>> >>> the OS and MS Paint i couldnt make these screeenshots and
> >>>>> >>> save them, since you can read nothing on any window or menu
> >>>>> >>> items,...
> >>>>> >>>
> >>>>> >>> Oh yes, why will the content from FreeMath rendered successfully
> >>>>> >>> and other apps not?
> >>>>> >>>
> >>>>> >>> Its OT but maybe someone is interessted in it and also can
> >>>>> >>> expplain
> >>>>> >>> me what and why this happens,...OS is SP3 WinXPPro, you propably
> >>>>> >>> already figured this out from the Screenshots,..
> >>>>> >>>
> >>>>> >>> Regards
> >>>>> >>>
> >>>>> >>> Kerem
> >>>>> >>>
> >>>>> >>> --
> >>>>> >>> -----------------------
> >>>>> >>> Beste Grüsse / Best regards / Votre bien devoue
> >>>>> >>> Kerem Gümrükcü
> >>>>> >>> Microsoft Live Space: http://kerem-g.spaces.live.com/
> >>>>> >>> Latest Open-Source Projects: http://entwicklung.junetz.de
> >>>>> >>> -----------------------
> >>>>> >>> "This reply is provided as is, without warranty express or
> >>>>> >>> implied."
> >>>>> >>
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>

==============================================================================
TOPIC: SetCommState - Does not seem to modify serial interface
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/b544f64630f6abe1?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 9:36 am
From: Jeanseb

Hi,

I'm trying to get access to the serial port on on Windows XP, using VC
2008.

Here is the code I am using:

int CCommunicationSerial::Init(
char const * const comPort, // in
const unsigned int baudRate, // in
const unsigned char bitsPerByte, // in
const eCommunicationSerialParity_t parity, // in
const float stopBits // in
)
{
// Function return value;
int result = -1;

// Communication port properties
DCB commProperties;

TCHAR szDevName[32];

// TODO: THIS IS TO BE FIXED
wsprintf(szDevName, TEXT("COM1"));

// Open the port in non overlapped mode
m_Handle = CreateFile( szDevName,
GENERIC_READ | GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
0, // non overlap
0);

if(INVALID_HANDLE_VALUE != m_Handle)
{
memset(&commProperties, 0, sizeof(commProperties));
commProperties.DCBlength = sizeof(DCB);

if(TRUE == GetCommState(m_Handle, &commProperties))
{
result = 0;
}

// Set the serial communication properties
// Initialize the DCB
// TODO: For now all of these contain hardcoded values.
// Some of these values are rather best-guessed and may not be
appropriate.
// Though it is important to specify default values that are
applied for
// each initialization so we insure the state of the harware
when the app
// starts.
commProperties.BaudRate = baudRate;
commProperties.fBinary = true; // Always with
Windows

switch(parity)
{
case COMMUNICATIONSERIALPARITY_NONE:
{
commProperties.fParity = false;
break;
}
default:
{}
} // switch(parity)

commProperties.fOutxCtsFlow = false;
commProperties.fOutxDsrFlow = false;
commProperties.fDtrControl = DTR_CONTROL_DISABLE;
commProperties.fDsrSensitivity = false;
commProperties.fTXContinueOnXoff = true;
commProperties.fOutX = false;
commProperties.fInX = false;
commProperties.fErrorChar = false;
commProperties.fNull = false;
commProperties.fRtsControl = RTS_CONTROL_DISABLE;
commProperties.fAbortOnError = true;
commProperties.fDummy2 = 0;
commProperties.wReserved = 0;
commProperties.XonLim = 2048;
commProperties.XoffLim = 512;
commProperties.ByteSize = 8;

commProperties.BaudRate = CBR_19200; // set the baud rate
commProperties.ByteSize = 8; // data size, xmit, and
rcv
commProperties.Parity = NOPARITY; // no parity bit
commProperties.StopBits = ONESTOPBIT; // one stop bit

switch(parity)
{
case COMMUNICATIONSERIALPARITY_NONE:
{
commProperties.Parity = NOPARITY;
break;
}
default:
{}
} // switch(parity)

if(1.0 == stopBits)
{
commProperties.StopBits = ONESTOPBIT;
}
else if (1.5 == stopBits)
{
commProperties.StopBits = ONE5STOPBITS;
}
else if (2 == stopBits)
{
commProperties.StopBits = TWOSTOPBITS;
}
else
{}

commProperties.XonChar = 17;
commProperties.XoffChar = 19;
commProperties.ErrorChar = 0;
commProperties.EofChar = 0;
commProperties.EvtChar = 0;
commProperties.wReserved1 = 0;

if(0 != SetCommState(m_Handle, &commProperties))
{
result = 0;
}
} // if(INVALID_HANDLE_VALUE != m_Handle)

return result;
} // CCommunicationSerial::Init

I want to configure the port as follow: 19200 bauds, no parity, no
hardware control.

If I run the code as is, my application is unable to read from the
port.

If I run Hyperterminal (19200 bauds, no parity, no hardware control)
and then execute this code, I can read from the serial port.

I believe I am covering all the settings that can be modified on the
serial port, though it looks like Hyperterminal does something else
that enables access to the serial port...

Any idea!?

Thanks

== 2 of 2 ==
Date: Mon, Jun 23 2008 6:12 pm
From: hammerli22

I don't know if this helps, but from the cmd line run the "mode" command to
see if your changes are taking effect.

Also how are you reading the serial port in your code ?

Whats your setup ? Are you running a null modem cable from a pc
to pc with one end running hyperterminal hooked up ?

Hyperterminal maybe asserting the DTR signal to your port allowing
data to come in so your target that replaces Hypertermnal may have to do the
same.

Get a break out box so you can monitor the pin outs
-M

"Jeanseb" wrote:

> Hi,
>
> I'm trying to get access to the serial port on on Windows XP, using VC
> 2008.
>
> Here is the code I am using:
>
> int CCommunicationSerial::Init(
> char const * const comPort, // in
> const unsigned int baudRate, // in
> const unsigned char bitsPerByte, // in
> const eCommunicationSerialParity_t parity, // in
> const float stopBits // in
> )
> {
> // Function return value;
> int result = -1;
>
> // Communication port properties
> DCB commProperties;
>
> TCHAR szDevName[32];
>
>
> // TODO: THIS IS TO BE FIXED
> wsprintf(szDevName, TEXT("COM1"));
>
> // Open the port in non overlapped mode
> m_Handle = CreateFile( szDevName,
> GENERIC_READ | GENERIC_WRITE,
> 0,
> 0,
> OPEN_EXISTING,
> 0, // non overlap
> 0);
>
> if(INVALID_HANDLE_VALUE != m_Handle)
> {
> memset(&commProperties, 0, sizeof(commProperties));
> commProperties.DCBlength = sizeof(DCB);
>
> if(TRUE == GetCommState(m_Handle, &commProperties))
> {
> result = 0;
> }
>
> // Set the serial communication properties
> // Initialize the DCB
> // TODO: For now all of these contain hardcoded values.
> // Some of these values are rather best-guessed and may not be
> appropriate.
> // Though it is important to specify default values that are
> applied for
> // each initialization so we insure the state of the harware
> when the app
> // starts.
> commProperties.BaudRate = baudRate;
> commProperties.fBinary = true; // Always with
> Windows
>
> switch(parity)
> {
> case COMMUNICATIONSERIALPARITY_NONE:
> {
> commProperties.fParity = false;
> break;
> }
> default:
> {}
> } // switch(parity)
>
> commProperties.fOutxCtsFlow = false;
> commProperties.fOutxDsrFlow = false;
> commProperties.fDtrControl = DTR_CONTROL_DISABLE;
> commProperties.fDsrSensitivity = false;
> commProperties.fTXContinueOnXoff = true;
> commProperties.fOutX = false;
> commProperties.fInX = false;
> commProperties.fErrorChar = false;
> commProperties.fNull = false;
> commProperties.fRtsControl = RTS_CONTROL_DISABLE;
> commProperties.fAbortOnError = true;
> commProperties.fDummy2 = 0;
> commProperties.wReserved = 0;
> commProperties.XonLim = 2048;
> commProperties.XoffLim = 512;
> commProperties.ByteSize = 8;
>
> commProperties.BaudRate = CBR_19200; // set the baud rate
> commProperties.ByteSize = 8; // data size, xmit, and
> rcv
> commProperties.Parity = NOPARITY; // no parity bit
> commProperties.StopBits = ONESTOPBIT; // one stop bit
>
>
> switch(parity)
> {
> case COMMUNICATIONSERIALPARITY_NONE:
> {
> commProperties.Parity = NOPARITY;
> break;
> }
> default:
> {}
> } // switch(parity)
>
> if(1.0 == stopBits)
> {
> commProperties.StopBits = ONESTOPBIT;
> }
> else if (1.5 == stopBits)
> {
> commProperties.StopBits = ONE5STOPBITS;
> }
> else if (2 == stopBits)
> {
> commProperties.StopBits = TWOSTOPBITS;
> }
> else
> {}
>
> commProperties.XonChar = 17;
> commProperties.XoffChar = 19;
> commProperties.ErrorChar = 0;
> commProperties.EofChar = 0;
> commProperties.EvtChar = 0;
> commProperties.wReserved1 = 0;
>
> if(0 != SetCommState(m_Handle, &commProperties))
> {
> result = 0;
> }
> } // if(INVALID_HANDLE_VALUE != m_Handle)
>
> return result;
> } // CCommunicationSerial::Init
>
>
> I want to configure the port as follow: 19200 bauds, no parity, no
> hardware control.
>
> If I run the code as is, my application is unable to read from the
> port.
>
> If I run Hyperterminal (19200 bauds, no parity, no hardware control)
> and then execute this code, I can read from the serial port.
>
> I believe I am covering all the settings that can be modified on the
> serial port, though it looks like Hyperterminal does something else
> that enables access to the serial port...
>
> Any idea!?
>
> Thanks
>

==============================================================================
TOPIC: Copy count in Minidriver is not changing
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/9c04fa2362779b8e?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jun 23 2008 9:38 am
From: Manfred Wilner

I am stuck with an issue regarding the copy count in the Printer Minidriver
setup.
It has worked for me in previous drivers but now that I started a new
project with the WDK 6000 files I have the problem that the copy count is not
changing.
I compile the driver in the XP environment right now with backward
compatibility for W2k.
I have checked differences against my working driver in the GPD file and the
UI OEM DLL but there are no noticable differences to be found.

Can anyone point me to a solution?

Thank you,
--
\Manfred

==============================================================================
TOPIC: Vista-like USB support on XP
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/88fa8e2d384e5552?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 9:57 am
From: ivk

Windows Vista supports WMCDC, and it provides User level USB support
via WinUSB interface. Is any of these available, may be from a 3d
party, on Windows XP ?

== 2 of 2 ==
Date: Mon, Jun 23 2008 11:27 am
From: "Doron Holan [MSFT]"

while you may not get the high leve labstractions from WMCDC (i have no idea
what this component is), but you can easily use winusb for low level I/O on
XP

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"ivk" <ivk2000@hotmail.com> wrote in message
news:5a453d83-d497-46b2-bed5-0e7c614b1a2b@s33g2000pri.googlegroups.com...
> Windows Vista supports WMCDC, and it provides User level USB support
> via WinUSB interface. Is any of these available, may be from a 3d
> party, on Windows XP ?

==============================================================================
TOPIC: Last NTFS volume/disk update time
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/16d357f168686d39?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jun 23 2008 10:11 am
From: krish

Is there any function/way to determine the last update time of a NTFS
volume? Thanks.

==============================================================================
TOPIC: get from KernelMode to UserMode very quickly?
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/a863d900d11376d5?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 10:33 am
From: "name"

Well, I did not intend to strike a nerve with anyone here! But if I did,
I'm sorry that happened.

Not all programmers are skilled in device driver composing. So I think
short-cuts, or hacks, back to user mode do have a certain allure.

Getting into (or notifying) the user mode thread that got was interrupted
(as quickly as possible) lets a programmer adjust the response to an
interrupt dynamically. Some specialty I/O is like that, where you get some
input bytes (or serial stream)coming at the CPU at unknown speed,
synchronization, framing; sometimes needing some quick simple
packing/unpacking and/or serialize/de-serialize, data conversion, etc.

Another common type of input is signals which are frequency or time-domain
shifted/encoded, so every interrupt needs a accurate timestamp associated
right away, which should be saved for analysis/decoding by the user mode
application.

Maybe the thing to ask then should be: What tools and information have
"evolved" recently, which can make device driver writing as easy as
application writing? As long as it remains a "black-art", hacks and crap
code will be attempted! Many of the Driver Wizard programs have faded away,
and I find only Jungo and Rapid Driver remain with any significant presence.
The choices are down from 1/2 dozen back in the late 90's, to just these 2;
and what they offer has not advanced much in the last decade it seems? A
typical applications programmer still cannot ramp up to Device Driver skill
level in mere days, which I don't think is unrealistic to expect, IF a
really good DDK was offered that included extensions to the familiar and
popular IDE's like Visual Studio, C+ Builder, or Delphi.

"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:eshWR7L1IHA.4772@TK2MSFTNGP03.phx.gbl...
> Why do you think you need this? I've encountered more crap code using
> various hacks to notify user space than I want to remember and in every
> case I have had a chence to test things, I found that dumping the "super
> fast" model for the normal inverted call has never impacted the overall
> performance of the app/driver combination. I'm sure there are cases
> where it is justified, but they are rare, especially as processors
> continue getting faster.
>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
>
>
>
> "name" <me@myplace.com> wrote in message
> news:fAA7k.25297$Jx.19057@pd7urf1no...
>> has anyone here every explored the following topic (with code sample) to
>> verify it works?
>>
>> is this still possible to do in Windows XP?
>>
>> is there any similar, newer, or even better "dirty tricks" to get from
>> KernelMode to UserMode very quickly?
>>
>>
>> found at: http://www.cmkrnl.com/arc-userapc.html
>>
>> Usenet Archives
>> User mode APCs
>> Author: Anatoly Vorobey
>> Date: 1997/05/08
>> Forum: comp.os.ms-windows.programmer.nt.kernel-mode
>> Posted on: 1997/05/08
>> Message-ID:
>> Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
>> Organization: Erol's Internet Services
>> Reply-To: mellon+usenet@pobox.com
>> X-Received-On: 8 May 1997 11:43:05 GMT
>>
>>
>> Hi there,
>>
>> The issue of notifying user-mode thread from a kernel-mode driver, or
>> calling a user-mode routine from same, is very often discussed here. The
>> usual solutions offered are: 1) a dedicated thread sending an IRP to the
>> driver which the driver leaves uncompleted and completes when it needs to
>> communicate information to the thread; and 2) signaling an event which
>> can be accessed in both user and kernel mode, with user-mode thread
>> waiting on it. Both these approaches have their drawbacks; in particular,
>> they need a dedicated thread waiting, and they're relatively slow -
>> sometimes you _know_ you're in the right context, and you just need to
>> tell something to the user-mode thread or pass some information to it as
>> soon as possible.
>>
>> I've tried to find other ways of doing the same, being driven mostly by
>> curiosity, spirit of exploration and stubborness. I've found two other
>> mechanisms by which it is possible to make a thread call some specific
>> user-mode function:
>>
>> 1. User-mode APC (Asynchronous Procedure Call). The whole issue of APCs
>> is quite undocumented in the DDK. Actually, more informatiion about APCs
>> can be found in Win32 SDK help than in NT DDK help! That's because the
>> whole mechanism of completion routine-based I/O routines (like
>> ReadFileEx(), etc.) is quite transparently based on APC, and the SDK help
>> says a few basic things about APCs. They're also discussed briefly in the
>> classic Helen Custer's "Inside Windows NT".
>>
>> The main problem with this approach is that according to the NT design
>> principles, a thread can receive a user-mode APC _only_ if it declares
>> itself alertable: either by waiting on a synchronization object with
>> alertable flag set on, or explicitly calling a certain function in
>> ntdll.dll to check whether it should be alerted. Since we _don't_ want
>> our thread to wait on anything (we may just as well use named event then)
>> we're stuck. In the code I give below, I overcome this problem in an
>> undocumented and somewhat dirty way; I'm still searching for more "clean"
>> ways to do it.
>>
>> When a user-mode APC is passed to a thread in this way, its routine be
>> called next time the thread runs in user-mode. If the thread already runs
>> in user-mode, the routine won't be invoked immediately, however; it'll be
>> called next time the thread _returns_ to user-mode from some kernel-mode
>> service. Usually that happens almost immediately since an active thread
>> is calling kernel-mode services all the time; in the worst case it'll
>> happen after the next clock tick, when clock tick procedure returns to
>> user-mode. The user-mode APC will not, however, interrupt any kernel-mode
>> activity; i.e. if the thread is waiting on an object, it won't be woken
>> up; when it wakes up by itself, however, it will receive the pending APC
>> immediately.
>>
>> 2. KeUserModeCallback(). This is an undocumented function used by Win32
>> subsystem running in the kernel in NT 4.0 (win32k.sys). It's used when
>> the subsystem either needs to know some information stored in user-mode
>> (for example, in user32.dll's data), or needs to call a thread's window
>> procedure (for example, when you move your mouse, the subsystem
>> eventually receives notification of it in kernel mode, and it calls your
>> window procedure with WM_MOUSEMOVE message using this function). A catch
>> here is that this mechanism is predefined to call only some specified
>> functions: one of parameters to KeUserModeCallback() is an index to a
>> special table from which later in user mode an address to call is
>> fetched. Still it's possible to exploit this mechanism to call, _very_
>> quickly (much quicker than the APC, named event or pending IRP mechanisms
>> allow) an arbitrary routine of your code. The catch here is that you
>> _must_ be in your thread's context for this to work; in this respect
>> user-mode APC is better since you can freely send it to any thread in the
>> system.
>>
>> Below is sample code that will send user-mode APC to the current thread,
>> calling an arbitrary user-mode routine and passing it three arbitrary
>> parameters. If you want to send an APC to your thread from arbitrary
>> context, you should capture its KTHREAD pointer by calling
>> KeGetCurrentThread() in _its_ context (say, when receiving a custom
>> control request from it and being top-level), and use it in a call to
>> KeInitializeApc later at any time.
>>
>> Unfortunately, it will only work on x86 architecture due to one
>> machine-dependent line which modifies directly the KTHREAD structure. It
>> should, however, work on free/checked builds and SMP/uniprocessor
>> machines alike. It's taken right out of an article I'm completing which
>> discusses in detail both kernel-mode and user-mode APCs; I'm still
>> uncertain whether I should simply put it on the web or try to offer it to
>> some paper magazines.
>>
>> If you're interested, please try out this code and report to me whether
>> it works/ doesn't work for you and what happens if it doesn't. Note that
>> I of course disclaim any responsibility; your system might very well
>> crash/bugcheck, though I've tested this code for some time now and it's
>> always been working fine for me.
>>
>>
>> /* The APC structure is defined in ntddk.h */
>>
>> /* this is KERNEL_ROUTINE for our APC; in particular, it gets
>> called when the APC is being delivered. Usually one of predefined
>> useful routines in the kernel are used for this purpose, but we
>> can't use any of them as none of them are exported. */
>>
>> void MyRoutine(struct _KAPC *Apc,
>> PKNORMAL_ROUTINE norm_routine,
>> void *context,
>> void *SysArg1,
>> void *SysArg2)
>> {
>> ExFreePool(Apc);
>> return;
>> }
>>
>> /* pointer to the APC we will create */
>>
>> static struct _KAPC *apc;
>>
>> /* KeInitializeApc() and KeInsertQueueApc() are the two functions
>> needed to send an APC; they're both exported but not prototyped
>> in the DDK, so we prototype them here. */
>>
>> void KeInitializeApc(struct _KAPC *Apc, PKTHREAD thread,
>> unsigned char state_index,
>> PKKERNEL_ROUTINE ker_routine,
>> PKRUNDOWN_ROUTINE rd_routine,
>> PKNORMAL_ROUTINE nor_routine,
>> unsigned char mode,
>> void *context);
>>
>>
>> void KeInsertQueueApc(struct _KAPC *APC,
>> void *SysArg1,
>> void *SysArg2,
>> unsigned char arg4);
>>
>> /* call this function when you need to send a user-mode APC to
>> the current thread. addr must be linear address of your user-mode
>> function to call:
>>
>> void MyApcRoutine(ULONG arg1, ULONG arg2, ULONG arg3);
>> ...
>> SendAddrToTheDriverUsingIoctl((ULONG)MyApcRoutine);
>>
>> you should send it to the driver using your custom IOCTL.
>> arg1, arg2, arg3 are arbitrary ulong's which are passed to the
>> function residing at addr; this function should be prototyped as
>> receiving three parameters and returning void. */
>>
>> void SendAPC(ULONG addr, ULONG arg1, ULONG arg2, ULONG arg3) {
>>
>> PKTHREAD thread=KeGetCurrentThread();
>>
>> /* this is self-explanatory */
>>
>> apc=ExAllocatePool(NonPagedPool, sizeof(struct _KAPC));
>>
>> /* Initialize the user-mode APC */
>>
>> KeInitializeApc(apc, thread, 0,
>> (PKKERNEL_ROUTINE)&MyRoutine, 0,
>> (PKNORMAL_ROUTINE)addr, 1, (PVOID)arg1);
>>
>> /* Insert it to the queue of the target thread */
>>
>> KeInsertQueueApc(apc, (PVOID)arg2, (PVOID)arg3, 0);
>>
>> /* Mark the current thread as alertable to force it to deliver
>> the APC on the next return to the user-mode.
>> NOTE: severely undocumented code here! */
>>
>> *((unsigned char *)thread+0x4a)=1;
>> }
>>
>>
>> That's about it. I'll be very grateful to hear comments, corrections,
>> additions or flames from you. Questions are always welcome.
>>
>> Yours,
>> Anatoly.
>>
>> --
>> Anatoly Vorobey,
>> mellon@pobox.com http://pobox.com/~mellon/
>> "Angels can fly because they take themselves lightly" - G.K.Chesterton
>>
>>
>
>

== 2 of 2 ==
Date: Mon, Jun 23 2008 11:41 am
From: "Don Burn"

Well you first question was asking for techniques that are on the high edge
of the driver world, now the questions have moved quite a bit. First on
your example needs, sorry but I will repeat the mantra said often in the
Windows driver forums "Windows is not a real time OS". So if you really
have needs like your examples, find another system or get one of the real
time extensions that run under Windows.

As far as the "black art" look at Windows Driver Framework. This removes
much of the pain of driver writing in Windows and can make it easier. I
have never encountered "Rapid Driver" but Jungo and some of the other
toolkits no longer supported, I keep getting requests for quotes from people
who need their driver rewritten to something more standard. The common
reasons are:

1. The latest OS is not supported and won't be for some time.
2. Some feature of the OS is not supported and it is hard to use it in
the framework.
3. The framework had enough prolblems that people wanted a solid
driver, and decided it was time to replace the stuff they had.

--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"name" <me@myplace.com> wrote in message
news:T7R7k.22521$kx.3756@pd7urf3no...
> Well, I did not intend to strike a nerve with anyone here! But if I did,
> I'm sorry that happened.
>
> Not all programmers are skilled in device driver composing. So I think
> short-cuts, or hacks, back to user mode do have a certain allure.
>
> Getting into (or notifying) the user mode thread that got was interrupted
> (as quickly as possible) lets a programmer adjust the response to an
> interrupt dynamically. Some specialty I/O is like that, where you get
> some input bytes (or serial stream)coming at the CPU at unknown speed,
> synchronization, framing; sometimes needing some quick simple
> packing/unpacking and/or serialize/de-serialize, data conversion, etc.
>
> Another common type of input is signals which are frequency or time-domain
> shifted/encoded, so every interrupt needs a accurate timestamp associated
> right away, which should be saved for analysis/decoding by the user mode
> application.
>
> Maybe the thing to ask then should be: What tools and information have
> "evolved" recently, which can make device driver writing as easy as
> application writing? As long as it remains a "black-art", hacks and crap
> code will be attempted! Many of the Driver Wizard programs have faded
> away, and I find only Jungo and Rapid Driver remain with any significant
> presence. The choices are down from 1/2 dozen back in the late 90's, to
> just these 2; and what they offer has not advanced much in the last decade
> it seems? A typical applications programmer still cannot ramp up to
> Device Driver skill level in mere days, which I don't think is unrealistic
> to expect, IF a really good DDK was offered that included extensions to
> the familiar and popular IDE's like Visual Studio, C+ Builder, or Delphi.
>
>
>
>
> "Don Burn" <burn@stopspam.windrvr.com> wrote in message
> news:eshWR7L1IHA.4772@TK2MSFTNGP03.phx.gbl...
>> Why do you think you need this? I've encountered more crap code using
>> various hacks to notify user space than I want to remember and in every
>> case I have had a chence to test things, I found that dumping the "super
>> fast" model for the normal inverted call has never impacted the overall
>> performance of the app/driver combination. I'm sure there are cases
>> where it is justified, but they are rare, especially as processors
>> continue getting faster.
>>
>>
>> --
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Website: http://www.windrvr.com
>> Blog: http://msmvps.com/blogs/WinDrvr
>> Remove StopSpam to reply
>>
>>
>>
>>
>> "name" <me@myplace.com> wrote in message
>> news:fAA7k.25297$Jx.19057@pd7urf1no...
>>> has anyone here every explored the following topic (with code sample) to
>>> verify it works?
>>>
>>> is this still possible to do in Windows XP?
>>>
>>> is there any similar, newer, or even better "dirty tricks" to get from
>>> KernelMode to UserMode very quickly?
>>>
>>>
>>> found at: http://www.cmkrnl.com/arc-userapc.html
>>>
>>> Usenet Archives
>>> User mode APCs
>>> Author: Anatoly Vorobey
>>> Date: 1997/05/08
>>> Forum: comp.os.ms-windows.programmer.nt.kernel-mode
>>> Posted on: 1997/05/08
>>> Message-ID:
>>> Newsgroups: comp.os.ms-windows.programmer.nt.kernel-mode
>>> Organization: Erol's Internet Services
>>> Reply-To: mellon+usenet@pobox.com
>>> X-Received-On: 8 May 1997 11:43:05 GMT
>>>
>>>
>>> Hi there,
>>>
>>> The issue of notifying user-mode thread from a kernel-mode driver, or
>>> calling a user-mode routine from same, is very often discussed here. The
>>> usual solutions offered are: 1) a dedicated thread sending an IRP to the
>>> driver which the driver leaves uncompleted and completes when it needs
>>> to communicate information to the thread; and 2) signaling an event
>>> which can be accessed in both user and kernel mode, with user-mode
>>> thread waiting on it. Both these approaches have their drawbacks; in
>>> particular, they need a dedicated thread waiting, and they're relatively
>>> slow - sometimes you _know_ you're in the right context, and you just
>>> need to tell something to the user-mode thread or pass some information
>>> to it as soon as possible.
>>>
>>> I've tried to find other ways of doing the same, being driven mostly by
>>> curiosity, spirit of exploration and stubborness. I've found two other
>>> mechanisms by which it is possible to make a thread call some specific
>>> user-mode function:
>>>
>>> 1. User-mode APC (Asynchronous Procedure Call). The whole issue of APCs
>>> is quite undocumented in the DDK. Actually, more informatiion about APCs
>>> can be found in Win32 SDK help than in NT DDK help! That's because the
>>> whole mechanism of completion routine-based I/O routines (like
>>> ReadFileEx(), etc.) is quite transparently based on APC, and the SDK
>>> help says a few basic things about APCs. They're also discussed briefly
>>> in the classic Helen Custer's "Inside Windows NT".
>>>
>>> The main problem with this approach is that according to the NT design
>>> principles, a thread can receive a user-mode APC _only_ if it declares
>>> itself alertable: either by waiting on a synchronization object with
>>> alertable flag set on, or explicitly calling a certain function in
>>> ntdll.dll to check whether it should be alerted. Since we _don't_ want
>>> our thread to wait on anything (we may just as well use named event
>>> then) we're stuck. In the code I give below, I overcome this problem in
>>> an undocumented and somewhat dirty way; I'm still searching for more
>>> "clean" ways to do it.
>>>
>>> When a user-mode APC is passed to a thread in this way, its routine be
>>> called next time the thread runs in user-mode. If the thread already
>>> runs in user-mode, the routine won't be invoked immediately, however;
>>> it'll be called next time the thread _returns_ to user-mode from some
>>> kernel-mode service. Usually that happens almost immediately since an
>>> active thread is calling kernel-mode services all the time; in the worst
>>> case it'll happen after the next clock tick, when clock tick procedure
>>> returns to user-mode. The user-mode APC will not, however, interrupt any
>>> kernel-mode activity; i.e. if the thread is waiting on an object, it
>>> won't be woken up; when it wakes up by itself, however, it will receive
>>> the pending APC immediately.
>>>
>>> 2. KeUserModeCallback(). This is an undocumented function used by Win32
>>> subsystem running in the kernel in NT 4.0 (win32k.sys). It's used when
>>> the subsystem either needs to know some information stored in user-mode
>>> (for example, in user32.dll's data), or needs to call a thread's window
>>> procedure (for example, when you move your mouse, the subsystem
>>> eventually receives notification of it in kernel mode, and it calls your
>>> window procedure with WM_MOUSEMOVE message using this function). A catch
>>> here is that this mechanism is predefined to call only some specified
>>> functions: one of parameters to KeUserModeCallback() is an index to a
>>> special table from which later in user mode an address to call is
>>> fetched. Still it's possible to exploit this mechanism to call, _very_
>>> quickly (much quicker than the APC, named event or pending IRP
>>> mechanisms allow) an arbitrary routine of your code. The catch here is
>>> that you _must_ be in your thread's context for this to work; in this
>>> respect user-mode APC is better since you can freely send it to any
>>> thread in the system.
>>>
>>> Below is sample code that will send user-mode APC to the current thread,
>>> calling an arbitrary user-mode routine and passing it three arbitrary
>>> parameters. If you want to send an APC to your thread from arbitrary
>>> context, you should capture its KTHREAD pointer by calling
>>> KeGetCurrentThread() in _its_ context (say, when receiving a custom
>>> control request from it and being top-level), and use it in a call to
>>> KeInitializeApc later at any time.
>>>
>>> Unfortunately, it will only work on x86 architecture due to one
>>> machine-dependent line which modifies directly the KTHREAD structure. It
>>> should, however, work on free/checked builds and SMP/uniprocessor
>>> machines alike. It's taken right out of an article I'm completing which
>>> discusses in detail both kernel-mode and user-mode APCs; I'm still
>>> uncertain whether I should simply put it on the web or try to offer it
>>> to some paper magazines.
>>>
>>> If you're interested, please try out this code and report to me whether
>>> it works/ doesn't work for you and what happens if it doesn't. Note that
>>> I of course disclaim any responsibility; your system might very well
>>> crash/bugcheck, though I've tested this code for some time now and it's
>>> always been working fine for me.
>>>
>>>
>>> /* The APC structure is defined in ntddk.h */
>>>
>>> /* this is KERNEL_ROUTINE for our APC; in particular, it gets
>>> called when the APC is being delivered. Usually one of predefined
>>> useful routines in the kernel are used for this purpose, but we
>>> can't use any of them as none of them are exported. */
>>>
>>> void MyRoutine(struct _KAPC *Apc,
>>> PKNORMAL_ROUTINE norm_routine,
>>> void *context,
>>> void *SysArg1,
>>> void *SysArg2)
>>> {
>>> ExFreePool(Apc);
>>> return;
>>> }
>>>
>>> /* pointer to the APC we will create */
>>>
>>> static struct _KAPC *apc;
>>>
>>> /* KeInitializeApc() and KeInsertQueueApc() are the two functions
>>> needed to send an APC; they're both exported but not prototyped
>>> in the DDK, so we prototype them here. */
>>>
>>> void KeInitializeApc(struct _KAPC *Apc, PKTHREAD thread,
>>> unsigned char state_index,
>>> PKKERNEL_ROUTINE ker_routine,
>>> PKRUNDOWN_ROUTINE rd_routine,
>>> PKNORMAL_ROUTINE nor_routine,
>>> unsigned char mode,
>>> void *context);
>>>
>>>
>>> void KeInsertQueueApc(struct _KAPC *APC,
>>> void *SysArg1,
>>> void *SysArg2,
>>> unsigned char arg4);
>>>
>>> /* call this function when you need to send a user-mode APC to
>>> the current thread. addr must be linear address of your user-mode
>>> function to call:
>>>
>>> void MyApcRoutine(ULONG arg1, ULONG arg2, ULONG arg3);
>>> ...
>>> SendAddrToTheDriverUsingIoctl((ULONG)MyApcRoutine);
>>>
>>> you should send it to the driver using your custom IOCTL.
>>> arg1, arg2, arg3 are arbitrary ulong's which are passed to the
>>> function residing at addr; this function should be prototyped as
>>> receiving three parameters and returning void. */
>>>
>>> void SendAPC(ULONG addr, ULONG arg1, ULONG arg2, ULONG arg3) {
>>>
>>> PKTHREAD thread=KeGetCurrentThread();
>>>
>>> /* this is self-explanatory */
>>>
>>> apc=ExAllocatePool(NonPagedPool, sizeof(struct _KAPC));
>>>
>>> /* Initialize the user-mode APC */
>>>
>>> KeInitializeApc(apc, thread, 0,
>>> (PKKERNEL_ROUTINE)&MyRoutine, 0,
>>> (PKNORMAL_ROUTINE)addr, 1, (PVOID)arg1);
>>>
>>> /* Insert it to the queue of the target thread */
>>>
>>> KeInsertQueueApc(apc, (PVOID)arg2, (PVOID)arg3, 0);
>>>
>>> /* Mark the current thread as alertable to force it to deliver
>>> the APC on the next return to the user-mode.
>>> NOTE: severely undocumented code here! */
>>>
>>> *((unsigned char *)thread+0x4a)=1;
>>> }
>>>
>>>
>>> That's about it. I'll be very grateful to hear comments, corrections,
>>> additions or flames from you. Questions are always welcome.
>>>
>>> Yours,
>>> Anatoly.
>>>
>>> --
>>> Anatoly Vorobey,
>>> mellon@pobox.com http://pobox.com/~mellon/
>>> "Angels can fly because they take themselves lightly" - G.K.Chesterton
>>>
>>>
>>
>>

==============================================================================
TOPIC: Avoiding PCI Resource allocation and PCI Bus filter driver
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/e347a80240f61968?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 11:23 am
From: "Doron Holan [MSFT]"

if you want to modify the resource list back to its original form, you can
do so in EvtDeviceFilterAddResourceRequirements

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:%23RyohmG1IHA.5300@TK2MSFTNGP06.phx.gbl...
> Then PCI.SYS seems to check that it's getting correct number of BARs in
> START_DEVICE.
>
> "Vasudevan Srinivasan" <vasuweb@gmail.com> wrote in message
> news:C4834CE0.2A19%vasuweb@gmail.com...
>> I'm trying to avoid the pnp manager from allocating an MMIO resource for
>> a
>> pci device even though the device has that resource available (There is
>> no
>> IOBAR equivalent to this MMIO bar, but, I do not want this MMIO bar for
>> the
>> device to be functional and this MMIO is not functioning as expected and
>> hence this requirement).
>>
>> I tried handling the EvtDeviceFilterRemoveResourceRequirements in the
>> function driver and tried to remove the memory resource, but, the device
>> yellow banged in device manager.
>>
>> I also read from the forums and WDK documentation that a bus filter
>> driver
>> could handle the IRP_MN_QUERY_RESOURCE_REQUIREMENTS (
>> EvtDeviceResourceRequirementsQuery in WDF?) and alter the resource
>> requirements.
>>
>> Question 1: Since my device is a PCI device (Bus X, Dev Y, Fn Z) that has
>> pci.sys as the bus driver, how do I install a bus filter driver for this
>> device? I need my function driver to install as well so would greatly
>> appreciate any pointers on how to setup the inf file for this filter
>> driver
>> (I would prefer a separate inf file for this filter driver if possible,
>> so I
>> can choose to install this filter or not). I'm assuming writing this
>> filter
>> driver itself shouldn't be a big deal as it could be a regular WDF driver
>> that adds the specific PNP event handler that I need.
>>
>> Question 2: Can I add this PDO event handler in my function driver
>> itself?
>> If so, will it automatically get tied to the PDO that my function driver
>> is
>> connecting to?
>>
>> Appreciate any help/pointers that would allow me to remove the Memory BAR
>> allocation by the PNP Manager and still allow my function driver to load
>> fine.
>>
>> Thanks,
>> Vasu.
>>
>
>

== 2 of 2 ==
Date: Mon, Jun 23 2008 8:57 pm
From: Tim Roberts

Vasudevan Srinivasan <vasuweb@gmail.com> wrote:
>
>I'm trying to avoid the pnp manager from allocating an MMIO resource for a
>pci device even though the device has that resource available (There is no
>IOBAR equivalent to this MMIO bar, but, I do not want this MMIO bar for the
>device to be functional and this MMIO is not functioning as expected and
>hence this requirement).
>
>I tried handling the EvtDeviceFilterRemoveResourceRequirements in the
>function driver and tried to remove the memory resource, but, the device
>yellow banged in device manager.

If you own the function driver, as the last sentence implies, then why
can't you just modify the driver to ignore the resource? No one else is
going to try to access your memory space.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

==============================================================================
TOPIC: BSOD with DRIVER_POWER_STATE_FAILURE (9f)
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/7e1273a325c2403d?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jun 23 2008 5:18 pm
From: hammerli22

My driver is BSOD when the system was gracefully powered down after it was
running for 48hrs. Am I missing the servicing of some power request ? It
never happened before and all of a sudden it happend but I am unable to
reproduce it and all i have is this memory dump and logs below. Any ideas ?

thanks

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too
long a time
Arg2: e000012783025590, Physical Device Object of the stack
Arg3: e00001278573fbe0, Functional Device Object of the stack
Arg4: e0000127851e5420, The blocked IRP

Debugging Details:
------------------

Page 1fc00 not present in the dump file. Type ".hh dbgerr004" for details

DRVPOWERSTATE_SUBCODE: 3

DEVICE_OBJECT: e00001278573fbe0

DRIVER_OBJECT: e000012785712b60

IMAGE_NAME: mydriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 47ebfe90

MODULE_NAME: mydriver

FAULTING_MODULE: e00001062101e000 mydriver

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: Idle

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from e000000088465730 to e0000000884645f0

STACK_TEXT:
e0000106`006e2f60 e0000106`006e4498 e0000000`88465730 : 00000000`0000009f
00000000`00000003 e0000127`83025590 e0000127`8573fbe0 : nt!KeBugCheck2+0x210
[d:\rtm\base\ntos\ke\bugcheck.c @ 813]
e0000106`006e3a90 e0000106`006e4460 e0000000`8837a110 : 00000000`0000009f
00000000`00000003 e0000127`83025590 e0000127`8573fbe0 : nt!KeBugCheckEx+0x30
[d:\rtm\base\ntos\ke\bugcheck.c @ 163]
e0000106`006e3a90 e0000106`006e43d8 e0000000`882d14e0 : e0000127`8517acc0
e0000127`851e5420 e0000127`8573fbe0 e0000127`851e5422 :
nt!PopCheckIrpWatchdog+0xa4fb0
e0000106`006e3ab0 e0000106`006e4340 e0000000`8829e960 : 00000000`00015edf
00000000`00000000 00000000`00000000 00000000`00000001 :
nt!PopCheckForIdleness+0x680 [d:\rtm\base\ntos\po\sidle.c @ 630]
e0000106`006e3ad0 e0000106`006e4218 e0000000`8829fe90 : e0000106`006e3ca0
00000000`00000002 e0000106`006e3c98 00000000`00000001 :
nt!KiTimerListExpire+0x560 [d:\rtm\base\ntos\ke\dpcsup.c @ 1048]
e0000106`006e3c80 e0000106`006e4178 e0000000`882a1ce0 : 00000000`000004e0
00000000`00000150 00000000`00000002 00000000`00000001 :
nt!KiTimerExpiration+0x2d0 [d:\rtm\base\ntos\ke\dpcsup.c @ 770]
e0000106`006e3ca0 e0000106`006e40e8 e0000000`8830a670 : e0000000`88680e80
e0000000`886820a0 e0000000`88682800 0000006a`28430796 :
nt!KiRetireDpcList+0x440 [d:\rtm\base\ntos\ke\dpcsup.c @ 1154]
e0000106`006e3cc0 e0000106`006e40d8 e0000000`882fffd0 : 00000000`00500000
0000006a`280628f6 e0000000`88680e80 e0000000`886820a0 :
nt!KiRetireDpcListEx+0x190 [d:\rtm\base\ntos\ke\mp\ctxswap.s @ 1873]
e0000000`87361d70 e0000000`87362088 00000000`00000000 : 00000000`00000189
00000000`00000000 00000000`00000000 e0000000`88682e10 :
nt!Kil_TopOfIdleLoop+0xd0 [d:\rtm\base\ntos\ke\mp\start.s @ 1305]

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: IA64_0x9F_IMAGE_mydriver.sys

BUCKET_ID: IA64_0x9F_IMAGE_mydriver.sys

Followup: MachineOwner
---------

kd> !devobj e00001278573fbe0 f
Device object (e00001278573fbe0) is for:
MYNAME \Driver\MYDRIVER DriverObject e000012785712b60
Current Irp 00000000 RefCount 5 Type 00000022 Flags 00002044
Dacl e0000107006c3781 DevExt e00001278573cfb0 DevObjExt e00001278573fd50
ExtensionFlags (0000000000)
AttachedTo (Lower) e000012783025590 \Driver\ACPI
Device queue is not busy.

kd> !WDFDEVICE 0x1ffffed87a8c33f8 f

Dumping WDFDEVICE 0x1ffffed87a8c33f8
=================================

WDM PDEVICE_OBJECTs:self e00001278573fbe0, attached e000012783025590, pdo
e000012783025590

Pnp state: 119 ( WdfDevStatePnpStarted )
Power state: 31a ( WdfDevStatePowerGotoDx )
Power Pol state: 527 ( WdfDevStatePwrPolSleepingNoWakePowerDown )

Default WDFIOTARGET: 1ffffed87a8c0c38

Pended device power irp 0xe0000127851e5420
Pended system power irp 0xe0000127851c8790
Device is the power policy owner for the stack

Pnp state history:
[0] WdfDevStatePnpObjectCreated (0x100)
[1] WdfDevStatePnpInit (0x105)
[2] WdfDevStatePnpInitStarting (0x106)
[3] WdfDevStatePnpHardwareAvailable (0x108)
[4] WdfDevStatePnpEnableInterfaces (0x109)
[5] WdfDevStatePnpStarted (0x119)

Power state history:
[0] WdfDevStatePowerStartingCheckDeviceType (0x316)
[1] WdfDevStatePowerD0Starting (0x30f)
[2] WdfDevStatePowerD0StartingConnectInterrupt (0x310)
[3] WdfDevStatePowerD0StartingDmaEnable (0x311)
[4] WdfDevStatePowerD0StartingStartSelfManagedIo (0x312)
[5] WdfDevStatePowerDecideD0State (0x313)
[6] WdfDevStatePowerD0 (0x307)
[7] WdfDevStatePowerGotoDx (0x31a)

Power policy state history:
[0] WdfDevStatePwrPolObjectCreated (0x500)
[1] WdfDevStatePwrPolStarting (0x501)
[2] WdfDevStatePwrPolStartingSucceeded (0x502)
[3] WdfDevStatePwrPolStartingDecideS0Wake (0x504)
[4] WdfDevStatePwrPolStarted (0x565)
[5] WdfDevStatePwrPolSleeping (0x526)
[6] WdfDevStatePwrPolSleepingNoWakePowerDown (0x527)

WDFCHILDLIST Handles:
!WDFCHILDLIST 0x1ffffed87a8c0218 (static PDO list)

Properties:
SynchronizationScope: WdfSynchronizationScopeDevice
ExecutionLevel: WdfExecutionLevelPassive
IoType: WdfDeviceIoBuffered
FileObjectClass: WdfFileObjectWdfCannotUseFsContexts
Exclusive: No
AutoForwardCleanupClose: No
DefaultIoPriorityBoot: 0
DeviceName: \Device\Myname
SymbolicLink: \DosDevices\Myname
MofResourceName: MofResourceName

kd> !wdfdevicequeues 0x1ffffed87a8c33f8

Dumping queues of WDFDEVICE 0x1ffffed87a8c33f8
=====================================
Number of queues: 2
----------------------------------
Queue: 1 (!wdfqueue 0x1ffffed87a8c08a8)
Manual, Not power-managed, PowerOn, Passive Only, Can accept, Can
dispatch, ExecutionLevelPassive, SynchronizationScopeDevice
Number of driver owned requests: 0
Number of waiting requests: 0

This is WDF internal queue for create requests.
----------------------------------
Queue: 2 (!wdfqueue 0x1ffffed87a8c1718)
Parallel, Default, Power-managed, PowerStartingTransition, Passive Only,
Can accept, Can dispatch, Dispatching, ExecutionLevelPassive,
SynchronizationScopeDevice
Number of driver owned requests: 1
!WDFREQUEST 0x1ffffed87af02f78 !IRP 0xe000012785217c00
Number of waiting requests: 1
!WDFREQUEST 0x1ffffed87af9b148 !IRP 0xe000012785048930

EvtIoDeviceControl: (0xe000010621032290) Mydriver!MyEvtIoDeviceControl

kd> !wdflogdump MYDRIVER
Trace searchpath is: C:\WINDDK\6001.18000\tools\tracing\i386\wdf01007.tmf

Trace format prefix is: %7!u!: %!FUNC! -
TMF file used for formatting IFR log is:
C:\WINDDK\6001.18000\tools\tracing\i386\wdf01007.tmf
Log at e000012785740000
Gather log: Please wait, this may take a moment (reading 8120 bytes).
% read so far ... 10, 20, 30, 40, 50, 60, 70, 80, 90, 100
There are 144 log entries
--- start of log ---

[... bunch of stuff deleted ...]

920: FxIoTargetRemote::ClearTargetPointers - WDFIOTARGET 1FFFFED87ADE6CF8
cleared pointers E00001062A754C30 state WdfIoTargetDeleted, open state 3, pdo
E000012782D27A30, fileobj E000012785209CB0, handle FFFFFFFF8000097C
921: FxIoTarget::WaitForDisposeEvent - WDFIOTARGET 1FFFFED87ADE6CF8, Waiting
on Dispose event E00001062A754BF0
922: FxIoTargetRemote::Close - WDFIOTARGET 1FFFFED87ADE6CF8 derefing PDO
E000012782D27A30 on close
923: FxIoTargetRemote::Close - WDFIOTARGET 1FFFFED87ADE6CF8 derefing FileObj
E000012785209CB0 on close
924: FxIoTargetRemote::Close - WDFIOTARGET 1FFFFED87ADE6CF8 closing handle
FFFFFFFF8000097C on close
925: FxPkgPnp::Dispatch - WDFDEVICE 0x1FFFFED87A8C33F8 !devobj
0xE00001278573FBE0 IRP_MJ_POWER, Minor 0x2 IRP 0xE0000127851C8790 for power
state S5
926: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x1FFFFED87A8C33F8
!devobj 0xE00001278573FBE0 entering power policy state
WdfDevStatePwrPolSleeping from WdfDevStatePwrPolStarted
927: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x1FFFFED87A8C33F8
!devobj 0xE00001278573FBE0 entering power policy state
WdfDevStatePwrPolSleepingNoWakePowerDown from WdfDevStatePwrPolSleeping
928: FxPkgPnp::Dispatch - WDFDEVICE 0x1FFFFED87A8C33F8 !devobj
0xE00001278573FBE0 IRP_MJ_POWER, Minor 0x2 IRP 0xE0000127851E5420 for power
state D3
929: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x1FFFFED87A8C33F8 !devobj
0xE00001278573FBE0 entering Power State WdfDevStatePowerGotoDx from
WdfDevStatePowerD0
---- end of log ----

kd> !IRP 0xE0000127851C8790
Irp is active with 4 stacks 3 is current (= 0xe0000127851c88f0)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace. Pending has
been returned
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 16, 0] 0 0 e000012783025590 00000000 e0000106016cb560-e00001278573e020

\Driver\ACPI Wdf01000!FxPkgFdo::_SystemPowerSxCompletion
Args: 00000000 00000000 00000000 00000005
>[ 16, 2] 0 e1 e00001278573fbe0 00000000 e00000008824bd10-e00001278580fe30 Success Error Cancel pending
\Driver\MYDRIVER nt!PopSystemIrpCompletion
Args: 00016600 00000000 00000006 00000005
[ 0, 0] 0 0 00000000 00000000 00000000-e00001278580fe30

Args: 00000000 00000000 00000000 00000000

kd> !irp e0000127851e5420
Irp is active with 4 stacks 3 is current (= 0xe0000127851e5580)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 e1 e00001278573fbe0 00000000 e00000008824c930-e00001278517acc0 Success Error Cancel pending
\Driver\MYDRIVER nt!PopRequestCompletion
Args: 00016600 00000001 00000004 00000005
[ 0, 0] 0 0 00000000 00000000 00000000-e00001278517acc0

Args: 00000000 00000000 00000000 00000000

kd> !stacks 0
Proc.Thread .Thread Ticks ThreadState Blocker
[e00001278288d350 System]
4.000008 e00001278288cde0 000029a GATEWAIT nt!KeWaitForGate+0x550
4.000010 e000012782890dc0 001bd97 Blocked nt!PopIrpWorkerControl+0x50
4.000014 e0000127828908e0 00001e4 Blocked
Wdf01000!FxIoQueue::WaitForSignal+0x1d0
4.000018 e000012782890400 000ec42 Blocked nt!PopIrpWorker+0x320
4.00001c e000012782960040 000eca8 Blocked nt!KeRemoveQueueEx+0x1330
4.000020 e000012782961b60 001bd97 Blocked nt!KeRemoveQueueEx+0x1330
4.000024 e000012782961680 001bd97 Blocked nt!KeRemoveQueueEx+0x1330
4.000028 e0000127829611a0 001bd97 Blocked nt!KeRemoveQueueEx+0x1330
4.00002c e000012782960cc0 001bd97 Blocked nt!KeRemoveQueueEx+0x1330
4.000030 e0000127829607e0 001bd97 Blocked nt!KeRemoveQueueEx+0x1330
4.000034 e000012782962040 0018a7e Blocked nt!KeRemoveQueueEx+0x1330
4.000038 e000012782963b60 000ed65 Blocked nt!KeRemoveQueueEx+0x1330
4.00003c e000012782963680 000ed96 Blocked
nt!PopDisplayResumeWorker+0x80
4.000040 e0000127829631a0 0018a7d Blocked nt!KeRemoveQueueEx+0x1330
4.000044 e000012782962cc0 000ed96 Blocked nt!KeRemoveQueueEx+0x1330
4.000048 e0000127829627e0 000ed96 Blocked nt!KeRemoveQueueEx+0x1330
4.00004c e000012782964040 000ed96 Blocked nt!KeRemoveQueueEx+0x1330
4.000050 e000012782965b60 000ed96 Blocked nt!KeRemoveQueueEx+0x1330
4.000054 e000012782965680 0000041 STANDBY nt!KeRemoveQueueEx+0x1330
4.000058 e0000127829651a0 000ed96 Blocked nt!KeRemoveQueueEx+0x1330
4.00005c e000012782964cc0 000ec44 Blocked nt!KeRemoveQueueEx+0x1330
4.000060 e0000127829647e0 0000041 Blocked nt!KeRemoveQueueEx+0x1330
4.000068 e000012782968560 0000044 Blocked nt!KiExecuteDpc+0x390
4.000070 e00001278296a8c0 001bda0 GATEWAIT nt!KeWaitForGate+0x550
4.00007c e00001278296d400 0000004 Blocked
nt!CcQueueLazyWriteScanThread+0xb0
4.000080 e00001278288a040 001bd97 Blocked nt!KeRemoveQueueEx+0x1330
4.000084 e00001278288bb60 001bd97 Blocked nt!KeRemoveQueueEx+0x1330
4.0000a8 e0000127829e36e0 001bd97 Blocked nt!EtwpLogger+0x120
4.0000ac e0000127829e5b60 001bd96 Blocked nt!EtwpLogger+0x120
4.0000b0 e0000127829e5200 001bd96 Blocked nt!EtwpLogger+0x120
4.0000b8 e000012782abd380 0000002 Blocked nt!WdipSemCheckTimeout+0x2e0
4.0000bc e000012782b00040 000ec42 Blocked nt!PopSleepDeviceList+0x300
4.0000c0 e000012782b00670 00194be Blocked acpi!ACPIWorkerThread+0xc0
4.0000c4 e000012782e04b80 001bd33 Blocked
pci!ExpressRootComplexPmeEventDispatcher+0xa0
4.0000c8 e000012782e07b60 001bd33 Blocked
pci!ExpressRootComplexPmeEventDispatcher+0xa0
4.0000cc e000012782e06e90 001bd33 Blocked
pci!ExpressRootComplexPmeEventDispatcher+0xa0
4.0000d0 e000012782e06600 001bd33 Blocked
acpi!PciRootBusBiosMethodDispatcherOnResume+0xa0
4.0000d4 e000012782d1d070 001bd33 Blocked
acpi!PciRootBusBiosMethodDispatcherOnResume+0xa0
4.0000d8 e000012782d24040 001bd20 Blocked
acpi!PciRootBusBiosMethodDispatcherOnResume+0xa0
4.0000dc e000012782d270d0 001bd20 Blocked
acpi!PciRootBusBiosMethodDispatcherOnResume+0xa0
4.0000e0 e000012782d54f60 001bd20 Blocked
acpi!PciRootBusBiosMethodDispatcherOnResume+0xa0
4.0000e4 e000012782d59420 001bd20 Blocked
acpi!PciRootBusBiosMethodDispatcherOnResume+0xa0
4.0000ec e0000127845bdaf0 001aa98 Blocked nt!KeRemoveQueueEx+0x1330
4.0000f0 e000012782851b60 00003f8 Blocked NDIS!ndisCmWaitThread+0x120
4.000104 e0000127846ca080 0000004 Blocked nt!KeRemoveQueueEx+0x1330
4.000108 e0000127846e5340 000ec9d Blocked
Ntfs!TxfPrivateThreadWorkerRoutine+0xe0
4.000114 e0000127857bb820 001b480 Blocked nt!KeRemoveQueueEx+0x1330
4.000118 e0000127857bb340 001b480 Blocked nt!KeRemoveQueueEx+0x1330
4.00011c e0000127857bae60 001b480 Blocked nt!KeRemoveQueueEx+0x1330
4.000120 e0000127857ba980 001b480 Blocked nt!KeRemoveQueueEx+0x1330
4.000124 e0000127857be040 001b480 Blocked nt!KeRemoveQueueEx+0x1330
4.000128 e0000127857bfb60 001b480 Blocked nt!KeRemoveQueueEx+0x1330
4.00012c e0000127857bf680 001b480 Blocked nt!KeRemoveQueueEx+0x1330
4.000170 e000012785cd65c0 00156a5 Blocked nt!KeRemoveQueueEx+0x1330
4.000174 e000012785cd0ae0 00156a5 Blocked nt!KeRemoveQueueEx+0x1330
4.000178 e000012785cda040 001b19e Blocked nt!KeRemoveQueueEx+0x1330
4.00017c e000012785cdbb60 001b19e Blocked nt!KeRemoveQueueEx+0x1330
4.000180 e000012785cdb680 001b19e Blocked nt!KeRemoveQueueEx+0x1330
4.000184 e000012785cdb1a0 0015ec5 Blocked nt!KeRemoveQueueEx+0x1330
4.000188 e000012785cdacc0 001b19e Blocked nt!KeRemoveQueueEx+0x1330
4.00018c e000012785cda7e0 0015ec5 Blocked nt!KeRemoveQueueEx+0x1330
4.000190 e000012785cdc040 001b19e Blocked nt!KeRemoveQueueEx+0x1330
4.000194 e000012785cddb60 001b19e Blocked nt!KeRemoveQueueEx+0x1330
4.000198 e000012785cdd680 001b19e Blocked nt!KeRemoveQueueEx+0x1330
4.00019c e000012785cdd1a0 00000d4 Blocked nt!KeRemoveQueueEx+0x1330
4.0001a0 e000012785cdccc0 00156a5 Blocked nt!KeRemoveQueueEx+0x1330
4.0001a4 e000012785cdc7e0 00156a5 Blocked nt!KeRemoveQueueEx+0x1330
4.0001fc e000012784580b40 001af81 Blocked
watchdog!SMgrGdiCalloutThread+0xd0
4.000254 e00001278483a590 000bfd8 Blocked nt!KeRemoveQueueEx+0x1330
4.00035c e00001278495f010 00079c1 Blocked
luafv!SynchronousFsControl+0x250
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
spsys.sys -
4.000464 e0000127849d8c90 001aad2 Blocked spsys+0x33390
4.000570 e000012784a7c400 001a9f8 Blocked mpsdrv!MpsWorkerThread+0x90
4.00060c e000012784b57930 0002196 Blocked HTTP!UlpScavengerThread+0x130
4.0005ec e000012784cbc520 00156a5 Blocked nt!KeRemoveQueueEx+0x1330
4.000650 e000012784cc1200 0015ec5 Blocked nt!KeRemoveQueueEx+0x1330
4.0006c0 e000012784cc5710 0019354 Blocked nt!KeRemoveQueueEx+0x1330
4.000780 e000012784f75b60 0019352 Blocked nt!KeRemoveQueueEx+0x1330
4.0007dc e000012784ccb120 0019350 Blocked nt!KeRemoveQueueEx+0x1330
4.000764 e000012784f77b60 001934f Blocked nt!KeRemoveQueueEx+0x1330
4.000d5c e00001278506a5b0 00001e2 Blocked nt!PopIrpWorker+0x320
4.000d54 e000012785180040 00001b1 Blocked nt!PopIrpWorker+0x320
4.000d40 e000012785212040 00001b1 Blocked nt!PopIrpWorker+0x320
4.000d3c e000012784cc7770 00001e2 Blocked nt!PopIrpWorker+0x320
4.000f10 e000012784f867c0 00001e4 Blocked nt!PopIrpWorker+0x320
4.000f0c e0000127850e6970 00001e4 Blocked nt!PopIrpWorker+0x320

==============================================================================
TOPIC: WinUSB coinstaller problem on 64-bit machines
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/7937cbdab1571f4d?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Jun 23 2008 5:37 pm
From: Paarvai Naai

Has anyone else experienced this issue?

Here are the steps to reproduce:

1) Use a 64-bit Vista machine that has the default WinUSB installed
2) Delete System32\winusb.dll and SysWow64\winusb.dll
3) Use an INF file that references the WinUSB co-installer
4) Install a device that invokes this INF file

System32\winusb.dll is restored, but SysWow64\winusb.dll is not.

This suggests that SysWow64\winusb.dll will not be installed or upgraded by
the coinstaller.

Any help would be most appreciated.

Thanks,
Paarvai

== 2 of 2 ==
Date: Mon, Jun 23 2008 8:04 pm
From: chris.aseltine@gmail.com

On Jun 23, 7:37 pm, Paarvai Naai
<PaarvaiN...@discussions.microsoft.com> wrote:

> System32\winusb.dll is restored, but SysWow64\winusb.dll is not.
>
> This suggests that SysWow64\winusb.dll will not be installed or upgraded by
> the coinstaller.

Does it work on Linux and Darwin?

==============================================================================
TOPIC: USBSTOR problem
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/4914577e39af0ea2?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jun 23 2008 6:33 pm
From: Ziv

Hi all,

I am writing a bus driver and there are some mass storage device
attached to my bus.

I got a crash after running few hours. I try to analyze cause but I
don't know how to mapping the problem to my driver.

Could you tell what kind of URB let my driver crash according to the
dump below? Thanks ^_^

Best regards,
Ziv

====================================================

Use !analyze -v to get detailed debugging information.

BugCheck C4, {53, 954cef20, 48706345, 95993d30}

Probably caused by : USBSTOR.SYS ( USBSTOR!USBSTOR_IsDeviceConnected
+d5 )

Followup: MachineOwner
---------

0: kd> .reload
Loading Kernel Symbols
.......................................................................................................................................
Loading User Symbols

Loading unloaded module list
.................................................
0: kd> .reload
Loading Kernel Symbols
.......................................................................................................................................
Loading User Symbols

Loading unloaded module list
.................................................
0: kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.
This is
because the driver was specified in the registry as being suspect (by
the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
0xA will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error
codes.
Typically the code is 0x1001 (deadlock detected) and
you can
issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 00000053, freeing memory where the caller has written past the
end of the
allocation, overwriting our stored virtual address.
Arg2: 954cef20, base address of the allocation,
Arg3: 48706345, header,
Arg4: 95993d30, (reserved)

Debugging Details:
------------------

BUGCHECK_STR: 0xc4_53

WRITE_ADDRESS: 954cef20 Nonpaged pool

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 81aee5a7 to 818d1163

STACK_TEXT:
90b55bfc 81aee5a7 000000c4 00000053 954cef20 nt!KeBugCheckEx+0x1e
90b55c1c 81ae8091 954cef20 48706345 954cef18 nt!
VerifierBugCheckIfAppropriate+0x32
90b55c38 818f23c2 954cef20 000000e0 00000000 nt!ViFreeTrackedPool+0x9e
90b55ca8 81841194 954cef20 00000000 90b55ce4 nt!ExFreePoolWithTag
+0x534
90b55cc4 81ae61cd 954cef20 00000000 954cef20 nt!IopFreeIrp+0x56
90b55cdc bcd90f55 00000000 00000000 957c05b8 nt!IovFreeIrpPrivate+0x58
90b55d08 bcd91bb9 957c0500 81906100 957c0500 USBSTOR!
USBSTOR_IsDeviceConnected+0xd5
90b55d30 81a2023b 957c0500 00000002 909fcd78 USBSTOR!
USBSTOR_ResetDeviceWorkItem+0x113
90b55d44 8183c41d 958dfd60 00000000 909fcd78 nt!IopProcessWorkItem
+0x23
90b55d7c 819d9a1c 958dfd60 468f5ab5 00000000 nt!ExpWorkerThread+0xfd
90b55dc0 81832a3e 8183c320 00000000 00000000 nt!PspSystemThreadStartup
+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
USBSTOR!USBSTOR_IsDeviceConnected+d5
bcd90f55 3bfb cmp edi,ebx

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: USBSTOR!USBSTOR_IsDeviceConnected+d5

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: USBSTOR

IMAGE_NAME: USBSTOR.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 47919052

FAILURE_BUCKET_ID: 0xc4_53_W_VRFK_USBSTOR!USBSTOR_IsDeviceConnected
+d5

BUCKET_ID: 0xc4_53_W_VRFK_USBSTOR!USBSTOR_IsDeviceConnected+d5

Followup: MachineOwner
---------

0: kd> !pool 954cef20
Pool page 954cef20 region is Nonpaged pool
954ce000 size: 40 previous size: 0 (Allocated) Vad
954ce040 size: 10 previous size: 40 (Free) .l..
954ce050 size: 40 previous size: 10 (Allocated) Vad
954ce090 size: 30 previous size: 40 (Allocated) Ntfn
954ce0c0 size: 70 previous size: 30 (Allocated) FMsl
954ce130 size: 40 previous size: 70 (Allocated) Vad
954ce170 size: 40 previous size: 40 (Allocated) Vad
954ce1b0 size: 70 previous size: 40 (Allocated) FMsl
954ce220 size: 70 previous size: 70 (Allocated) FMsl
954ce290 size: 18 previous size: 70 (Allocated) MmSi
954ce2a8 size: 30 previous size: 18 (Allocated) Ntfn
954ce2d8 size: e8 previous size: 30 (Allocated) Irp
954ce3c0 size: 38 previous size: e8 (Allocated) FMvj
954ce3f8 size: a0 previous size: 38 (Allocated) ViMm
954ce498 size: 30 previous size: a0 (Allocated) FSro
954ce4c8 size: 30 previous size: 30 (Allocated) FSro
954ce4f8 size: 70 previous size: 30 (Allocated) FMsl
954ce568 size: 38 previous size: 70 (Allocated) FMvj
954ce5a0 size: 40 previous size: 38 (Allocated) Vad
954ce5e0 size: 48 previous size: 40 (Allocated) Ntfr
954ce628 size: 78 previous size: 48 (Allocated) FMfc
954ce6a0 size: 38 previous size: 78 (Allocated) Even
(Protected)
954ce6d8 size: 48 previous size: 38 (Allocated) Ntfr
954ce720 size: 10 previous size: 48 (Free) FMsl
954ce730 size: d0 previous size: 10 (Allocated) File
(Protected)
954ce800 size: 48 previous size: d0 (Allocated) Ntfr
954ce848 size: 30 previous size: 48 (Allocated) Ntfx
954ce878 size: 48 previous size: 30 (Allocated) Ntfr
954ce8c0 size: 128 previous size: 48 (Allocated) Ntfi
954ce9e8 size: 2c0 previous size: 128 (Allocated) Thre
(Protected)
954ceca8 size: 8 previous size: 2c0 (Free) FMng
954cecb0 size: 90 previous size: 8 (Allocated) MmCa
954ced40 size: 18 previous size: 90 (Allocated) MmSi
954ced58 size: 28 previous size: 18 (Allocated) VfAT
954ced80 size: 30 previous size: 28 (Allocated) Ntfx
954cedb0 size: 38 previous size: 30 (Allocated) Even
(Protected)
954cede8 size: 48 previous size: 38 (Allocated) Ntfr
954cee30 size: 8 previous size: 48 (Free) FMsl
954cee38 size: 50 previous size: 8 (Allocated) CM44 Process:
9544ad88
954cee88 size: 50 previous size: 50 (Allocated) CM44 Process:
9544ad88
954ceed8 size: 40 previous size: 50 (Allocated) AlIn
*954cef18 size: e8 previous size: 40 (Allocated) *Irp
Pooltag Irp : Io, IRP packets

==============================================================================
TOPIC: How to disallow sleep/hibernation in Windows Vista ?
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/410e16ad5534dc24?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jun 23 2008 6:52 pm
From: "bhlx88@gmail.com"

Thanks ,KenSnyder and David Craig

==============================================================================

You received this message because you are subscribed to the Google Groups "microsoft.public.development.device.drivers"
group.

To post to this group, visit http://groups.google.com/group/microsoft.public.development.device.drivers?hl=en

To unsubscribe from this group, send email to microsoft.public.development.device.drivers-unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/microsoft.public.development.device.drivers/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com?hl=en

hoonzang's CFPs

2008-06-23

25 new messages in 15 topics - digest

No comments:

About Me

Search This Blog

Blog Archive

Followers

hoonzang's CFPs

2008-06-23

25 new messages in 15 topics - digest

No comments:

About Me

Search This Blog

Blog Archive

Subscribe To

Followers