Hypervisor-based transport for KD

TheMSsForum.com: The Microsoft Software Forum

The MSS Forum ‹ Drivers
- Archive
  - Biz
  - MCSE
  - CRM
  - Drivers
  - Framework
  - ADO
  - ASP
  - Compact
  - Forms
  - Dotnet
  - C#
  - VB
  - FontpageGen
  - Excel
  - WorkSheet
  - Exchange
  - Setup
  - Fox
  - Fontpage
  - ASP
  - IIS
  - Entourage
  - Money
  - Messanger
  - PocketPC
  - Powerpoint
  - Project
  - Publisher
  - Excel
  - VB
  - Security
  - Portal
  - Services
  - SQLServerDev
  - SVCS
  - SQLServer
  - VB
  - VC
  - MFC
  - ExcelGen

- Previous
  - 1
    - Creating a "virtual" drive ? Hello, I'm trying to create a virtual drive, aka I want a X: drive which isn't really existing (listing files from differents places and or virtual files, and being accessible through the OS filesystem by 3rd parties applications). I've downloaded the latest WDK and read through the doc etc ... Can someone tell me if what I want to do can be done using UMDF, or if I must do a kernel mode driver ? Basically the way I see it, what I would need would be a filter driver alone in its stack, am I right ? Is there any sample in particular that I should have a look at ? Thanks in advance Tag: Hypervisor-based transport for KD Tag: 102944
  - 2
    - LAN91C driver Regarding Hi, I added LAN91C driver to OS design (wince 5.0)and i am getting the following debug messages. DLL is detaching once its initialized LAN91C111 <= DriverEntry ndisMInitializeAdapter: Miniport 00039018, ==>ndisQueueMiniportOnDriver: Miniport 00039018, MiniBlock 00031020 <==ndisQueueMiniportOnDriver: Miniport 00039018, MiniBlock 00031020, rc 1 ==>NdisMSetAttributesEx: Miniport 00039018 ***NDIS*** (a, 534) ==>NdisMRegisterInterrupt: Miniport 00039018 Vector 9 NDIS:: CeConnectInterrupt() --> IRQ[9] SYSINTR[26] ***NDIS*** (a, 753) <==NdisMRegisterInterrupt: Miniport 00039018, Status 0 ***NDIS*** (a, 767) ==>NdisMDeregisterInterrupt: Miniport 00039018 ***NDIS*** (a, 861) <==NdisMDeregisterInterrupt: Miniport 00039018 ==>NdisMDeregisterAdapterShutdownHandler: Miniport 00039018 <==NdisMDeregisterAdapterShutdownHandler: Miniport 00039018 ***NDIS*** (b, 2078) INIT FAILURE: Dequeueing the miniport from the driver block. ==>ndisDeQueueMiniportOnDriver, Miniport 00039018, MiniBlock 00031020 <==ndisDeQueueMiniportOnDriver: Miniport 00039018, MiniBlock 00031020 ***NDIS*** (b, 2105) INIT FAILURE: Dereferencing the miniport block. ndisDereferenceMiniport:Miniport 00039018, Ref = 0 ==>ndisMUnload: DriverObject 00038BF0 ndisMUnload: MiniBlock 00031020 <==ndisMUnload: DriverObject 00038BF0, MiniBlock 00031020 LAN91C111: DLL Process Detach I got the firmware from MSDN only . Even this driver dooesn't verify the IOBase address Suggest me how to proceed. Regards, Kiruthika Tag: Hypervisor-based transport for KD Tag: 102943
  - 3
    - How do you create multiple device symbolic links for a single devi I've got a custom PCI device with 4 distinct channels, and need to create 4 unique device symbolic links, i.e. pci_device_0, pci_device_1, pci_device_2, pci_device_3. I've added the following to my EvtWdfDriverDeviceAdd() routine, and the calls don't fail, but the sym links do not appear to be created, CreateFile() FAILS. PWDFDEVICE_INIT device_init; WDFDEVICE child_device= NULL; DECLARE_UNICODE_STRING_SIZE( device_name, 64 ); for (i=0;i<4;i++) { if ((device_init=WdfPdoInitAllocate( parent_device ))==NULL) { return( STATUS_DEVICE_CONFIGURATION_ERROR ); } if (WdfDeviceCreate( &device_init, WDF_NO_OBJECT_ATTRIBUTES, &child_device )!=STATUS_SUCCESS) { return( STATUS_DEVICE_CONFIGURATION_ERROR ); } RtlUnicodeStringPrintf( &device_name, L"\\DosDevices\\pci_device_%d", i ); WdfDeviceCreateSymbolicLink( child_device, &device_name ); if (WdfFdoAddStaticChild( parent_device, child_device )!=STATUS_SUCCESS) { return( STATUS_DEVICE_CONFIGURATION_ERROR ); } } Tag: Hypervisor-based transport for KD Tag: 102938
  - 4
    - CreateNamedPipe function for kernel-mode? Is there a helper function or otherwise that would allow me to create a named pipe in a kernel-mode device driver? I have a named-pipe server that currently runs as a user-mode service and needs to accept connections from other workstations. I'd like to move it to kernel- mode. It doesn't do much, mostly just CreateNamedPipe and ReadFileEx and WriteFileEx on the pipe. Tag: Hypervisor-based transport for KD Tag: 102937
  - 5
    - iscsiprt.sys crash Hi, I keep getting a iscsiprt.sys crash as per below, does anyone have any detailed MS iSCSI knowledge that can help ? ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If kernel debugger is available get stack backtrace. Arguments: Arg1: 0000000000000068, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, value 0 = read operation, 1 = write operation Arg4: fffffadf2628112d, address which referenced memory Debugging Details: ------------------ Unable to load image \SystemRoot\system32\DRIVERS\iscsiprt.sys, Win32 error 0n2 *** WARNING: Unable to verify timestamp for iscsiprt.sys WRITE_ADDRESS: 0000000000000068 CURRENT_IRQL: 2 FAULTING_IP: iscsiprt!RaidUnitClaimIrp+11d fffffadf`2628112d ?? ??? CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP BUGCHECK_STR: 0xD1 PROCESS_NAME: System TRAP_FRAME: fffffadf243c6900 -- (.trap 0xfffffadf243c6900) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=00000000000000ff rbx=0000000000000000 rcx=0000000000000000 rdx=fffffadf380ec840 rsi=0000000000000c90 rdi=fffffadf37e7a730 rip=fffffadf2628112d rsp=fffffadf243c6a90 rbp=fffffadf380ec840 r8=fffffadf243c6bc0 r9=0000000000000000 r10=fffffadf28ef7998 r11=fffffadf243c6b98 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc iscsiprt!RaidUnitClaimIrp+0x11d: fffffadf`2628112d ?? ??? Resetting default scope LAST_CONTROL_TRANSFER: from fffff8000102e5b4 to fffff8000102e890 STACK_TEXT: fffffadf`243c6778 fffff800`0102e5b4 : 00000000`0000000a 00000000`00000068 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx fffffadf`243c6780 fffff800`0102d547 : fffffadf`374977a0 fffff800`011a95b4 00000000`00000000 fffffadf`37132060 : nt!KiBugCheckDispatch+0x74 fffffadf`243c6900 fffffadf`2628112d : 00000000`00000103 fffffadf`2955f4c5 fffffadf`37e7a730 00000000`00000200 : nt!KiPageFault+0x207 fffffadf`243c6a90 fffffadf`26282124 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffadf`37268af0 : iscsiprt!RaidUnitClaimIrp+0x11d fffffadf`243c6af0 fffffadf`262828c8 : 00000000`00000000 fffff800`0128e1e0 00000000`00000000 fffffadf`380ec840 : iscsiprt!RaUnitStartResetIo+0x104 fffffadf`243c6ba0 fffffadf`26282dec : 00000000`00000000 fffffadf`3801a960 fffffadf`37268af0 fffffadf`380ec840 : iscsiprt!RaUnitResetBusSrb+0x78 fffffadf`243c6bf0 fffffadf`2627ea3c : fffffadf`37268af0 fffffadf`37268af0 00000000`00000000 fffffadf`3801a960 : iscsiprt!RaUnitScsiIrp+0x1fc fffffadf`243c6c30 fffffadf`26280ad0 : fffffadf`380cdbd0 fffffadf`37268af0 fffffadf`370ec7a0 fffff800`011cd9c0 : iscsiprt!RaidUnitResetUnit+0xcc fffffadf`243c6ca0 fffff800`0128e1f8 : 00000000`00000000 fffffadf`37065db0 fffff800`011cd9c0 fffffadf`370ec7a0 : iscsiprt!RaidHierarchicalResetWorkRoutine+0x20 fffffadf`243c6cd0 fffff800`010375ca : 00000000`000000e5 fffffadf`25b36300 fffffadf`243c6d30 fffffadf`37065e18 : nt!IopProcessWorkItem+0x17 fffffadf`243c6d00 fffff800`0124a972 : fffffadf`370ec7a0 00000000`00000080 fffffadf`370ec7a0 fffffadf`29a93680 : nt!ExpWorkerThread+0x13b fffffadf`243c6d70 fffff800`01020226 : fffffadf`29a8b180 fffffadf`370ec7a0 fffffadf`29a93680 fffff800`011b4dc0 : nt!PspSystemThreadStartup+0x3e fffffadf`243c6dd0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16 STACK_COMMAND: kb FOLLOWUP_IP: iscsiprt!RaidUnitClaimIrp+11d fffffadf`2628112d ?? ??? SYMBOL_STACK_INDEX: 3 SYMBOL_NAME: iscsiprt!RaidUnitClaimIrp+11d FOLLOWUP_NAME: MachineOwner MODULE_NAME: iscsiprt IMAGE_NAME: iscsiprt.sys DEBUG_FLR_IMAGE_TIMESTAMP: 47466dea FAILURE_BUCKET_ID: X64_0xD1_W_iscsiprt!RaidUnitClaimIrp+11d BUCKET_ID: X64_0xD1_W_iscsiprt!RaidUnitClaimIrp+11d Followup: MachineOwner Tag: Hypervisor-based transport for KD Tag: 102930
  - 6
    - how to print the "expanded" TOC Anyone know how to print the "expanded" TOC ... http://msdn2.microsoft.com/en-us/library/ms795005.aspx Tag: Hypervisor-based transport for KD Tag: 102929
  - 7
    - Asynchronous command buffer processing Hi, Is there any way to force DX runtime to issue a drawprimitives2 call with D3DNTHALDP2_SWAPCOMMANDBUFFER flag set? According to MSDN this allows the driver to return immediately and process the buffer asynchronously. but I cannot figure out under what circumstances the flag is set. Regards, Tag: Hypervisor-based transport for KD Tag: 102928
  - 8
    - What is "pass IRP down the PnP stack"? in PortCls? When explaining IO_REMOVE_LOCK and how to use it, Walter Oney says in his book: "Whenever you receive an I/O request ***that you plan to forward down the stack***, you call IoAcquireRemoveLock." I even found a post that emphasizes this issue even more: http://tinyurl.com/277aqn In which he clarifies: "Claim the remove lock ***before passing an IRP down the PnP stack***, and release it when the IRP completes. It's not necessary to use the lock for an IRP that you don't pass down." and continues: "What you're really doing with the remove lock is making sure you don't call IoDetachDevice and don't return from your IRP_MN_REMOVE_DEVICE handler while ***the lower driver*** is processing an IRP you've sent it." (the "***" are my own emphasis) OK - so I understand that calling IoAcquireRemoveLock is not necessary in every type of IRP handling but rather only for those that are "passed down the PnP stack". However, I am unsure what "pass IRP down the PnP stack" means in the context of PortCls (see diagram): http://msdn2.microsoft.com/en-us/library/ms790577.aspx Specifically, when I call PcDispatchIrp(), does that constitute "pass IRP down the PnP stack"? And what is "the PnP stack" in this context? I know what an "IRP stack" is, but this is the first time I encounter the term "PnP stack". Could that have been a typo (in Mr. Oney's reply)? Thanks, Don Tag: Hypervisor-based transport for KD Tag: 102925
  - 9
    - Unable to Debug Drivers on Windows 2008 Server using WinDBG Hi Folks, On the Windows 2008 Server Machine , I have executed the following commands to enable debugging. bcdedit /dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200 bcdedit /debug on After executing these commands, I can see Windows 2008 Server Debugger Enabled in the OS Selection Screen. I have installed a WinDBG on another Win2k3 server. But I don't get any print statements or Im unable to break into the server by pressing the Break button on the WinDBG. Are there any known issues in debugging driver on Windows 2008. I have cross checked the NULL Modem cable and its working fine. Regards, NHKR Tag: Hypervisor-based transport for KD Tag: 102924
  - 10
    - KMDF: how can I get usb continuous reader callbacks always in order? Hi all, I'm using the continous reader functions in KMDF for a bulk read transfer on a device that has a serial (CAN) bus. It's important that the data comes in order in the driver's buffer, but I've seen issues on multi processor machines. I know that the callback can run at the same time on different processors, but how can I make sure to lock so all read buffer is processed in the right order? Currently, I use a spinlock in the beginning of the callback, but that is not theoretically safe, as the thread can be interrupted before the spinlock is acquired and the next callback eventually runs on the other processor (or?). I've seen it happend when we used very small buffers for the usb transfer (to get low bus latency). I use several queued reads, up to ten is supported I suppose. Regards, Carl-Magnus Segerlund Tag: Hypervisor-based transport for KD Tag: 102914
  - 11
    - Why this asymmetry in driver init/uninit API? For the function DriverEntry() there is the opposite callback DriverUnload(). This is symmetrical (and easy to remember/understand). For IRP_MN_START_DEVICE there is the opposite IRP_MN_STOP_DEVICE. This is symmetrical (and easy to remember/understand). But for the function AddDevice() there is no corresponding (i.e. symmetrical) RemoveDevice(). Instead, there is a minor IRP_MJ_PNP hanlder: IRP_MN_REMOVE_DEVICE. There must be a GOOD reason for this exception/asymmetry, right? If so, what is it? Thanks, Don (who tries to understand a little deeper) Tag: Hypervisor-based transport for KD Tag: 102911
  - 12
    - How implement replacement for USB interrupt transfers. Hello, due to bug in Windows USB stack, I need implement replacement for interrupt transfers by some self timed bulk transfer. Now are interrupt transfers pooled with 4ms period (it's high speed device). Simulated interrupt transfers may pool endpoint in 8ms period. First idea is similar as normal handling of interrupt implementation in driver - send URB, wait for completition, wait approximately 7-8ms and again send URB. There are some difficulties starting from precise timing, increased procesor time consuming and so on. Second idea is schedule transfer at specified frame number. Known somebody way how schedule trasfer at specified frame number? Or suggest something other? Slavo Tomascik Tag: Hypervisor-based transport for KD Tag: 102904
  - 13
    - Cancel Sub-Irps within a complete routine The situation: I have a USB driver using Bulk transfers. Large Bulk requests are splitted into 512KB chunks. To do so, the main Irp creates multiple sub Irps with a completion routine down the USB stack. After the last sub Irp completes, I complete the main Irp too. Since the device is sometimes not able to deliver enough data, I like to complete the main IRP of this incomplete USB transfer as soon as possible then (so the device would be able to send immediately fresh data for the next overlapped request - in our case an image). The problem: I detect a short transfer in my completion routine of a sub-irp and have to cancel immediately all other sub-irps as well. I know that this is usually done by IoCancelIrp, but I am in an awkward situation here, because I am already in a complete routine. How can I complete the other sub-irps and the main irp from a completion routine? Thanks in advance, Christoph Tag: Hypervisor-based transport for KD Tag: 102900
  - 14
    - What Could Possibly Crash PnpRemoveDevice()? I have written this audio driver which is pretty stable when playing/ recording sound. However, when I try to update the driver (via Device Manager), it generates a Fatal System Error: *** Fatal System Error: 0x0000000a (0x00000000,0x00000002,0x00000001,0x80525722) with the following stack trace: nt!RtlpBreakWithStatusInstruction nt!KiBugCheckDebugBreak+0x19 nt!KeBugCheck2+0xa51 nt!KiTrap0E+0x233 nt!PoRegisterDeviceForIdleDetection+0x46 nt!PoRunDownDeviceObject+0x1c nt!IoDeleteDevice+0x4d portcls!PnpRemoveDevice+0x8f portcls!DispatchPnp+0xce portcls!PcDispatchIrp+0x34 adrvr!MyPnpHandler+0x236 <<<<<<< only function that is mine nt!IopfCallDriver+0x31 nt!IopSynchronousCall+0xb7 nt!IopRemoveDevice+0x93 nt!IopRemoveLockedDeviceNode+0x160 nt!IopDeleteLockedDeviceNode+0x34 nt!IopDeleteLockedDeviceNodes+0x3f nt!PiProcessQueryRemoveAndEject+0x76b nt!PiProcessTargetDeviceEvent+0x2a nt!PiWalkDeviceList+0x122 nt!ExpWorkerThread+0x100 nt!PspSystemThreadStartup+0x34 nt!KiThreadStartup+0x16 Clearly, bugcheck analysis gives me a strong clue where to look for: MyPnpHandler(). Well, what I do in MyPnpHandler() is basically this: NTSTATUS YzPnpHandler(IN PDEVICE_OBJECT fdo, IN PIRP irp) { PAGED_CODE(); ASSERT(fdo != NULL); ASSERT(irp != NULL); if (OurFDO(fdo) && pIoStackLocation->MinorFunction == IRP_MN_REMOVE_DEVICE) { // stop thread and wait for its exit } return ( PcDispatchIrp(fdo, irp) ); // pass the IRPs on to PortCls } It seems that one of (or both?) paramaters to PcDispatchIrp are invalid by the time PcDispatchIrp is called? But how is this possible? as seen in my code, both fdo and irp are used successfully and *never modified* until they reach PcDispatchIrp(fdo, irp). How is this possible? What Could Possibly Crash PnpRemoveDevice()? Thanks, Don Tag: Hypervisor-based transport for KD Tag: 102899
  - 15
    - Tool for driver stack Hi Is there any tool which permits exploring the driver stack for a device? I used devcon and device manager till now but they are hard to use for this purpose ... What I want to achieve is a diagram similiar from this page: http://msdn2.microsoft.com/en-us/library/aa490242.aspx Or at least a clearer picture about my device and all layers below ... Is it possible at least? -- -Barni Tag: Hypervisor-based transport for KD Tag: 102897
  - 16
    - NDISTest failures in ad hoc mode We are trying to run NDIS test on WLan devices. NDIS test reports failure during association in the ad hoc mode. WE observe that the NDISMIndicateStatus as connected is sent by the miniport driver post Link sense event but NDIS reports time out saying that the Support device failed to join the network This is consistently observed while running the disassociate eml Another observation: If both the DUT and the suppport device are on the same machine the test passes Tag: Hypervisor-based transport for KD Tag: 102896
  - 17
    - Virtual COM Port I need to develop a Virtual COM port drive, which needs to act as a bridge between legacy applications (using COM ports) and a USB driver (Which is already available). To the legacy applications, this should look/feel/act like a COM port, but internally, the driver needs to communicate with the USB driver for the needful. I have stared with the serail driver sample provided with DDK as the base, is that the right place to start? Any design guidelines I should keep in mind? Also, is there any available sample code, which can be used for reference. Tag: Hypervisor-based transport for KD Tag: 102891
  - 18
    - VIA OHCI Compliant IEEE 1394 Host Controller This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C8690E.A11B2AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i am trying to fine a driver for VIA OHCI Compliant IEEE 1394 Host = Controller can anyone help me. went to about every web site you can = think about and no go. it is for a texas firewire pc card.=20 ------=_NextPart_000_0015_01C8690E.A11B2AF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY> <DIV><FONT face=3DArial size=3D2>i am trying to fine a driver for VIA = OHCI Compliant=20 IEEE 1394 Host Controller  </FONT>can anyone help me. went to = about=20 every web site you can think about and no go. it is for a texas firewire = pc=20 card. </DIV> <DIV><FONT face=3DArial size=3D2></FONT> </DIV></BODY></HTML> ------=_NextPart_000_0015_01C8690E.A11B2AF0-- Tag: Hypervisor-based transport for KD Tag: 102884
  - 19
    - PCI Interrupts I was reading through the sample driver for Plx9656 included with the DDK, and I noticed that there does not seem to be any code to handle PCI bus interrupts like parity error (PERR), system error (SERR), master abort and targer abort. Are these interrupts handled by the PCI bus driver? Or do these interrupts need to be handled by my functional driver? Tag: Hypervisor-based transport for KD Tag: 102883
  - 20
    - enabling WDK diskperf output I'm using WDK diskperf sample to monitor the disk accesses. I have few questions: 1. How can I enable the output of DbgPrint on WinDbg console or to some other file? I see that DiskPerfDebug is always set to 0 and so the following condition will be satisfied only for DebugPrintLevel=0. if ((DebugPrintLevel <= (DiskPerfDebug & 0x0000ffff)) || ((1 << (DebugPrintLevel + 15)) & DiskPerfDebug)) { DbgPrint(DebugMessage, ap); } Anyways I removed the above condition and call DbgPrint always. But still I do not see any output on WinDbg. Also I changed the: nt!kd_default_mask in winDbg to the following: dd nt!kd_default_mask 81cfbeb8 ffffffff 00000000 00000000 00000000 81cfbec8 00000000 00000000 00000000 00000000 81cfbed8 00000000 00000000 00000000 00000000 81cfbee8 00000000 00000000 00000000 00000000 81cfbef8 00000000 00000000 00000000 00000000 81cfbf08 00000000 00000000 00000000 00000000 81cfbf18 00000000 00000001 00000000 00000000 81cfbf28 00000000 00000000 00000000 00000000 But no luck. Any help will be highly appreciated. 2. Also is there any way of determining the process whose request generated the corresponding IOCTL that I see inside the diskperf? Thanks. Tag: Hypervisor-based transport for KD Tag: 102873
  - 21
    - WDK 6001 for user-mode code Who of us uses DDK/WDK for user mode builds too, like me? I have an issue using WDK 6001 for user-mode builds. The thing is that, if I define USE_STL (now a must to use STL), then WDK tries to link ntstc_msvcrt.lib (is it STL?), which _clashes_ with the msvcrt.lib import library on "operator delete". Is there any ways of solving this except defining my own "operator delete" in one of the .CPP files? -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.com Tag: Hypervisor-based transport for KD Tag: 102865
  - 22
    - Crash of WDK 6001 BUILD.EXE Reported to MS using Windows Error Reporting. Crash occurs if the directory listed in DIRS is absent. -- Maxim Shatskih, Windows DDK MVP StorageCraft Corporation maxim@storagecraft.com http://www.storagecraft.com Tag: Hypervisor-based transport for KD Tag: 102862
  - 23
    - Can touchpad driver be wrapped? Is it possible to create a wrapper for an OEM touchpad driver (Synaptics, Alps, etc) that intercepts the raw data from the touchpad driver and rewrites it before passing it along to Windows itself (Vista in particular, if it matters)? For the past few months I've been shopping for a new laptop, and it's increasingly difficult to get one with a pointer stick instead of/in addition to a touchpad.The problem is, I despise touchpads. Strangely, I actually LIKED the marble-like trackball on the laptop I had back in college (DEC HiNote Ultra). I spent a few hours thinking about what specifically irritated me about touchpads, and finally nailed down a good part of the answer: touchpad behavior is optimized for people using it with their index finger, not for people trying to treat it like a fake trackball and use it with their thumb while the fingers remain over the keyboard. The X and Y axes are scaled the same, even though the thumb's range of motion along the X axis is a lot more restricted than its motion along the Y axis. Moreover, the tracking algorithm doesn't take into account the fact that someone trying to treat the touchpad like a fake trackball and move the pointer diagonally (say, towards the lower-left corner of the screen) is going to move their thumb in a curved trajectory. So... the idea I came up with was to write a wedge/wrapper that sits between the raw Synaptics/Alps touchpad driver and Windows, and rewrites its output on the fly so that it DOES mimic the behavior of a trackball. The big question is, WHERE in the API would something like this be handled? Is there a whitepaper/book/article somewhere that explores this issue? Or, god forbid, has someone already written a driver (or at least the skeleton of one) that does something like this? I know I can't be the only person who hates the way touchpads work and has thought about trying to change that behavior to something more tolerable :) Tag: Hypervisor-based transport for KD Tag: 102856
  - 24
    - IRP_MJ_READ problem I have an application running on Windows Server 2003, that, according to PortMon monitoring software, is using calls to IRP_MJ_READ to read data from a serial port. Normally, to read a 37 byte message (for example), there will be a series of 4 calls to IRP_MJ_READ that result in 8 bytes of data from each read, then a final call that reads the final 5 bytes. Everything works fine. Occasonally, during the series of reads (let's say the 3rd read for example), the call to IRP_MJ_READ will result in 16 bytes of data (32 bytes read total so far), and no more calls to IRP_MJ_READ. The final 5 bytes of data are forever lost (a protocol analyzer trace shows that the entire 37 bytes entered the DB9 connector on the back of tyhe server). The application that was waiting for the data continues to issue calls to IOCTL_SERIAL_GET_COMMSTATUS, IOCTL_SERIAL_GET_MODEMSTATUS, and IOCTL_SERIAL_WAIT_ON_MASK, but the remaing 5 bytes never show up, so it times out while waiting for an ETX character that is at the end of the missing bytes. Any ideas on what could be causing this? I am not a developer, but am stuck in the middle of a lot of finger pointing between the server manufacturer (with their hardened drivers) and the application developer that is using the serial data. Any help you could give me that would give me some "ammo" so I can lean on the appropriate vendor would be helpful. Thank you. Tag: Hypervisor-based transport for KD Tag: 102853
  - 25
    - GetOverlappedResult() and IoStatus.Information The MSDN documentation for lpNumberOfBytesTransferred in GetOverlappedResult() says: BOOL WINAPI GetOverlappedResult( __in HANDLE hFile, __in LPOVERLAPPED lpOverlapped, __out LPDWORD lpNumberOfBytesTransferred, __in BOOL bWait ); >>> lpNumberOfBytesTransferred "A pointer to a variable that receives the number of bytes that were actually transferred by a read or *write* operation. For a DeviceIoControl operation, this is the number of bytes of output data returned by the device driver." Now, for the life of me, I just don't seem to understand a very basic issue here: What is that mystical "the number of bytes of output data returned by the device driver" when doing a WRITE operation (via a DeviceIoControl call)? Case in question: I wrote a driver that responds to DeviceIoControl() commands, supporting overlapped I/O in both read and write directions. With read I have no problems. However, with write, I just don't seem to get the crux of this lpNumberOfBytesTransferred (or IoStatus.Information in the driver). In my driver, when I do: pIRP->IoStatus.Information = actualNumberWritten; // 0 <= int <= 512 The GetOverlappedResult() call on the user mode side (the application that uses the driver) crashes the program! But when I do: pIRP->IoStatus.Information = pIRPStack->Parameters.DeviceIoControl.OutputBufferLength; The program doesn't crash. Now... I thought that, just as the GetOverlappedResult() documentation says, IoStatus.Information should return "the number of bytes that were actually transferred by a write operation". So what's going on here? Why must IoStatus.Information, on a DeviceIoControl *write* operation, return the size of the output buffer instead of "the number of bytes that were actually transferred by a write operation"? What am I missing here? Thanks, Don Tag: Hypervisor-based transport for KD Tag: 102851
- Next
  - 1
    - Re-enumerating usb devices Hi, So far I have been able to programatically re-enumerate usb devices using CM_Reenumerate_Devnode_Ex. Now, I have a situation where in I have a USB device whose device drivers are missing and hence it is not configured (connected but not configured) but then I want to re-enumerate it programatically. How would I do this? Any comments are welcome Thanks, Sri Tag: Hypervisor-based transport for KD Tag: 102841
  - 2
    - Registry setting for many Device drivers Hi, I have many device drivers named DIPSWITCH,LED,MICOM,ADC etc... In platform.reg if i register for this driver under [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IOD] "Prefix"="ADC" "Dll"="adc.dll" "Order"=dword:1 [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IOD] "Prefix"="micom" "Dll"="micom.dll" "Order"=dword:1 [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IOD] "Prefix"="dipswitch" "Dll"="dipswitch.dll" "Order"=dword:1 [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IOD] "Prefix"="IOD" "Dll"="iod.dll" "Order"=dword:1 [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\IOD] "Prefix"="led" "Dll"="led.dll" "Order"=dword:1 Only one driver dipswich.dll is getting loaded. i checked the registry of target device. How can i set in platform.reg for these drivers. Please Suggest me. Regards, Kirthika Tag: Hypervisor-based transport for KD Tag: 102839
  - 3
    - ioctl in a bus filter driver I have a bus filter driver in which I am registering an interface for a special IOCTL call (I want to return status information on a PCI-Express switch) I am able to get the device interface details using the setupDI calls and it looks good, but when I call CreateFile I get an invalid handle and the last error code is 2 (file does not exist). I have breakpoints in the Create/close routine and IOCTL dispatch routine, but the driver does not appear to be getting called. Tag: Hypervisor-based transport for KD Tag: 102830
  - 4
    - installing multiple devices with one driver my UMDF driver emulates a com port and works fine now. It is possible to have more than one device controlled by the driver, but when I install this, every time i install the driver again, it first reinstals the existing instances. Since the driver is not signed, this means that I have to confirm once for one device, 3 times for 2 devices, 6 times for 3 devices and so on. How can I avoid this? Thanks, Jan Tag: Hypervisor-based transport for KD Tag: 102829
  - 5
    - Can't turn on WDF Verifier I'm trying to turn on the WDF verifier, but !wdfdriverinfo <drivername> 0x1 is always reporting that the verifier is off. I've tried setting HKLM\System\CurrentControlSet\Services\<my driver>\Parameters\Wdf\VerifierOn to a 1, and restarted the driver and that didn't work. I also tried setting VerifyOn to as 1, and that didn't work either. Finally I tried using WdfVerifier.exe, but WinDbg is still reporting the verifier as being off. What am I missing? Thanks, Michael Tag: Hypervisor-based transport for KD Tag: 102827
  - 6
    - Aesthetic Perfection MP3s download A E S T H E T I C P E R F E C T I O N F R E E M P 3 S O N G S *Close To Human 2005* 'Aesthetic Perfection - Architect' (http://tinyurl.com/yqm8b7) (5:03 7.59Mb 210kbps) 'Aesthetic Perfection - Coward' (http://tinyurl.com/2xomcf) (5:02 7.27Mb 203kbps) 'Aesthetic Perfection - Ersatz' (http://tinyurl.com/249ctj) (5:43 8.12Mb 199kbps) 'Aesthetic Perfection - Fix' (http://tinyurl.com/yofa4l) (4:51 7.63Mb 221kbps) 'Aesthetic Perfection - Human' (http://tinyurl.com/294so8) (0:55 0.84Mb 128kbps) 'Aesthetic Perfection - I Belong To You' (http://tinyurl.com/2xa2uv) (3:31 5.37Mb 213kbps) 'Aesthetic Perfection - Overcast' (http://tinyurl.com/2au7ga) (5:36 7.97Mb 199kbps) 'Aesthetic Perfection - Relapse' (http://tinyurl.com/ypbgxm) (2:20 2.76Mb 166kbps) 'Aesthetic Perfection - Reset' (http://tinyurl.com/22vkjy) (3:51 5.88Mb 214kbps) 'Aesthetic Perfection - Sacrifice' (http://tinyurl.com/2h3flh) (3:19 5.32Mb 224kbps) 'Aesthetic Perfection - Surface' (http://tinyurl.com/yr3rpo) (4:03 6.61Mb 228kbps) 'Aesthetic Perfection ' (http://mp3tube.info/aesthetic_perfection/), 'Aesthetic Perfection Close To Human free MP3 song' (http://mp3tube.info/aesthetic_perfection/) -- Amdefalee87 ------------------------------------------------------------------------ Posted via http://www.codecomments.com ------------------------------------------------------------------------ Tag: Hypervisor-based transport for KD Tag: 102813
  - 7
    - OS platform for Win2K only in INF file . [install-section-name.NTx86] contains Windows 2000-specific instructions for installing the device or set of device-compatible models on all Windows 2000 x86-based platforms. . [install-section-name.NT] contains Windows 2000-specific instructions for installing the device or set of device-compatible models on all Windows 2000 platforms. Currently, .NT represents the same set of platforms that are defined by .ntx86. If non-x86 platforms are supported by Windows 2000 in the future, .NT will represent the set containing .ntx86 platforms and those new platforms. . [install-section-name] contains Windows 9x-specific instructions. Undecorated sections are also fallback sections for Windows 2000 platforms. Setup uses undecorated sections on Windows 2000 if it cannot locate the appropriate decorated sections. However, to prevent Windows 2000 sections from being used on Windows 9x by mistake, you should decorate any Windows 2000-specific DDInstall and related sections with the .ntx86 or .nt extensions. ======================================================= I have one question for Windows 2000 driver for one single INF file to install driver for XP, Vista and Windows 2000. According to the above description, how do I specify an platform extension that is only picked up by Windows 2000 but not XP and Vista. Tag: Hypervisor-based transport for KD Tag: 102796
  - 8
    - PM IRPs won't complete in KMDF bus driver Hi, I have a problem with a KMDF bus driver where the bus driver does not transition its stack back to D0 upon receiving a request on its PDOs to transition to D0 as a result of system entering S0. This problem happens intermittently, only on some hosts and mainly on Vista (occasionally seen on Win2k and XP). This is the scenario: host is put in S1 state and awoken after 20s (using WDTF) and this cycles through. After few cycles, screen comes up as either blank or blank with the mouse pointer frozen. System is not responsive and has to be cold-restarted. If I break into the debugger at this time, stack backtrace shows CPUs (multiprocessor system) are idle and there doesn't seem to be any deadlocks. There are several power IRPs active in the system at this point, the ones of my interest being child FDOs' SET_POWER S0s being pended on SET_POWER D0s it had sent. SET_POWER D0s are then pending in the bus driver for unknown reason. Looking at the KMDF logs, I can see that PDOs have received the SET_POWER D0 IRP, but for some reason they are waiting for the parent transition to D0 which never seems to happen. I have included the results of !WDFDEVICE for child PDO and parent bus FDO as well as last bits of KMDF logs. Could this be due to a potential race condition in the Framework as problem seems to occur more frequently when the number of childs is increased? As power mangement is handled by the Framework, I couldn't think of a way to take this any further. What else would you recommend to gather more information on this? Many thanks, DaveH //////////////////////// Child PDO 1: kd> !wdfdevice 0x77bf6900 fff Dumping WDFDEVICE 0x77bf6900 ================================= WDM PDEVICE_OBJECTs: self 91ffe9a8 Pnp state: 119 ( WdfDevStatePnpStarted ) Power state: 32f ( WdfDevStatePowerWaitForParent ) Power Pol state: 571 ( WdfDevStatePwrPolDx ) Parent WDFDEVICE 701ff620 Parent states: Pnp state: 119 ( WdfDevStatePnpStarted ) Power state: 31f ( WdfDevStatePowerDx ) Power Pol state: 515 ( WdfDevStatePwrPolSystemWakeDeviceWakeEnabledWakeCanceled ) Pended device power irp 0x95af2f00 (D0) 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] WdfDevStatePowerStartSelfManagedIo (0x32b) [1] WdfDevStatePowerD0BusWakeOwner (0x309) [2] WdfDevStatePowerGotoDx (0x31a) [3] WdfDevStatePowerGotoDxIoStopped (0x31c) [4] WdfDevStatePowerDx (0x31f) [5] WdfDevStatePowerCheckDeviceType (0x301) [6] WdfDevStatePowerCheckParentState (0x303) [7] WdfDevStatePowerWaitForParent (0x32f) Power policy state history: [0] WdfDevStatePwrPolGotoD0 (0x572) [1] WdfDevStatePwrPolStartingSucceeded (0x502) [2] WdfDevStatePwrPolGotoDx (0x56f) [3] WdfDevStatePwrPolDx (0x571) [4] WdfDevStatePwrPolGotoD0 (0x572) [5] WdfDevStatePwrPolStartingSucceeded (0x502) [6] WdfDevStatePwrPolGotoDx (0x56f) [7] WdfDevStatePwrPolDx (0x571) EvtDeviceEnableWakeAtBus: Mf!ChildEvtDeviceEnableWakeAtBus (8651be9a) EvtDeviceDisableWakeAtBus: Mf!ChildEvtDeviceDisableWakeAtBus (8651bece) Properties: SynchronizationScope: WdfSynchronizationScopeNone ExecutionLevel: WdfExecutionLevelDispatch IoType: WdfDeviceIoBuffered FileObjectClass: WdfFileObjectNotRequired Exclusive: No AutoForwardCleanupClose: No DefaultIoPriorityBoot: 2 //////////////////////// Bus FDO 1: kd> !WDFDEVICE 0x701ff620 fff Dumping WDFDEVICE 0x701ff620 ================================= WDM PDEVICE_OBJECTs:self 92c43c50, attached 8f5f9020, pdo 83c20030 Pnp state: 119 ( WdfDevStatePnpStarted ) Power state: 31f ( WdfDevStatePowerDx ) Power Pol state: 515 ( WdfDevStatePwrPolSystemWakeDeviceWakeEnabledWakeCanceled ) Default WDFIOTARGET: 6d3d4438 No pended pnp or power irps 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] WdfDevStatePowerWaking (0x333) [1] WdfDevStatePowerWakingConnectInterrupt (0x335) [2] WdfDevStatePowerWakingDmaEnable (0x339) [3] WdfDevStatePowerStartSelfManagedIo (0x32b) [4] WdfDevStatePowerD0 (0x307) [5] WdfDevStatePowerGotoDx (0x31a) [6] WdfDevStatePowerGotoDxIoStopped (0x31c) [7] WdfDevStatePowerDx (0x31f) Power policy state history: [0] WdfDevStatePwrPolSleeping (0x526) [1] WdfDevStatePwrPolSleepingWakePowerDown (0x52a) [2] WdfDevStatePwrPolSleepingSendWake (0x52b) [3] WdfDevStatePwrPolCheckPowerPageable (0x510) [4] WdfDevStatePwrPolSleepingWakeWakeArrived (0x511) [5] WdfDevStatePwrPolSystemAsleepWakeArmed (0x513) [6] WdfDevStatePwrPolSystemWakeDeviceWakeEnabled (0x514) [7] WdfDevStatePwrPolSystemWakeDeviceWakeEnabledWakeCanceled (0x515) EvtDeviceD0Entry: Mf!BusEvtDeviceD0Entry (8651acc8) EvtDevicePrepareHardware: Mf!BusEvtDevicePrepareHardware (8651b83a) EvtDeviceReleaseHardware: Mf!BusEvtDeviceReleaseHardware (8651b5e0) EvtDeviceArmWakeFromS0: Mf!BusEvtDeviceArmWake (8651acf8) EvtDeviceDisarmWakeFromS0: Mf!BusEvtDeviceDisarmWake (8651b638) EvtDeviceArmWakeFromSx: Mf!BusEvtDeviceArmWake (8651acf8) EvtDeviceDisarmWakeFromSx: Mf!BusEvtDeviceDisarmWake (8651b638) WDFCHILDLIST Handles: !WDFCHILDLIST 0x701566f8 (static PDO list) Properties: SynchronizationScope: WdfSynchronizationScopeNone ExecutionLevel: WdfExecutionLevelDispatch IoType: WdfDeviceIoBuffered FileObjectClass: WdfFileObjectNotRequired Exclusive: No AutoForwardCleanupClose: No DefaultIoPriorityBoot: 0 //////////////////////// KMDF log 3234: FxPkgPnp::Dispatch - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 IRP_MJ_POWER, Minor 0x2 IRP 0x972EAED8 3235: FxPkgPnp::Dispatch - WDFDEVICE 0x77BF6900 !devobj 0x91FFE9A8 IRP_MJ_POWER, Minor 0x2 IRP 0x9721EF00 3236: FxPkgPnp::Dispatch - WDFDEVICE 0x6E0C75D8 !devobj 0x92C1A480 IRP_MJ_POWER, Minor 0x2 IRP 0x9926AF00 3237: FxPkgPnp::Dispatch - WDFDEVICE 0x7BC2D768 !devobj 0x92C51530 IRP_MJ_POWER, Minor 0x2 IRP 0x97358F00 3238: FxPkgPnp::Dispatch - WDFDEVICE 0x6D3C1748 !devobj 0x91F39030 IRP_MJ_POWER, Minor 0x2 IRP 0x99388F00 3239: FxPkgPnp::Dispatch - WDFDEVICE 0x6E0C6E48 !devobj 0x92C5ACD0 IRP_MJ_POWER, Minor 0x2 IRP 0x992BEF00 3240: FxPkgPnp::Dispatch - WDFDEVICE 0x762E57C0 !devobj 0x89CB5A48 IRP_MJ_POWER, Minor 0x2 IRP 0x973E6F00 3241: FxPkgPnp::Dispatch - WDFDEVICE 0x6D398480 !devobj 0x84382AD8 IRP_MJ_POWER, Minor 0x2 IRP 0x993BEF00 3242: FxPkgPnp::Dispatch - WDFDEVICE 0x6D39E210 !devobj 0x92C56C50 IRP_MJ_POWER, Minor 0x2 IRP 0x95ADCF00 3243: FxPkgPnp::Dispatch - WDFDEVICE 0x77BF6900 !devobj 0x91FFE9A8 IRP_MJ_POWER, Minor 0x2 IRP 0x95AF2F00 3244: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x77BF6900 !devobj 0x91FFE9A8 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3245: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x77BF6900 !devobj 0x91FFE9A8 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3246: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3247: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3248: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x77BF6900 !devobj 0x91FFE9A8 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState 3249: FxPkgPnp::Dispatch - WDFDEVICE 0x6E0C75D8 !devobj 0x92C1A480 IRP_MJ_POWER, Minor 0x2 IRP 0x99272F00 3250: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6E0C75D8 !devobj 0x92C1A480 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3251: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6E0C75D8 !devobj 0x92C1A480 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3252: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3253: FxPowerIdleMachine::InDxIoIncrement - WDFDEVICE 701FF620 idle (in Dx) not sending io present event (already sent) 3254: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3255: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6E0C75D8 !devobj 0x92C1A480 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState 3256: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power policy state WdfDevStatePwrPolSystemWakeDeviceWakeEnabled from WdfDevStatePwrPolSystemAsleepWakeArmed 3257: FxPkgPnp::PowerPolicyCancelWaitWake - Successfully got WaitWake irp 99246ED8 for cancelling 3258: FxPkgPnp::_PowerPolicyWaitWakeCompletionRoutine - Completion of WaitWake irp 99246ED8, 0xc0000120(STATUS_CANCELLED) 3259: FxPkgPnp::_PowerPolicyWaitWakeCompletionRoutine - Not completing WaitWake irp 99246ED8 in completion routine 3260: FxPkgPnp::PowerPolicyCancelWaitWake - Cancel of irp 99246ED8 returned 1 3261: FxPkgPnp::PowerPolicyEnterNewState - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power policy state WdfDevStatePwrPolSystemWakeDeviceWakeEnabledWakeCanceled from WdfDevStatePwrPolSystemWakeDeviceWakeEnabled 3262: FxPkgPnp::PowerPolicySendDevicePowerRequest - Requesting D0 irp, 0x00000103(STATUS_PENDING) 3263: FxPkgPnp::Dispatch - WDFDEVICE 0x7BC2D768 !devobj 0x92C51530 IRP_MJ_POWER, Minor 0x2 IRP 0x993C0F00 3264: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7BC2D768 !devobj 0x92C51530 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3265: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7BC2D768 !devobj 0x92C51530 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3266: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3267: FxPowerIdleMachine::InDxIoIncrement - WDFDEVICE 701FF620 idle (in Dx) not sending io present event (already sent) 3268: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3269: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x7BC2D768 !devobj 0x92C51530 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState 3270: FxPkgPnp::Dispatch - WDFDEVICE 0x6D3C1748 !devobj 0x91F39030 IRP_MJ_POWER, Minor 0x2 IRP 0x8B2AEF00 3271: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D3C1748 !devobj 0x91F39030 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3272: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D3C1748 !devobj 0x91F39030 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3273: FxPkgPnp::Dispatch - WDFDEVICE 0x6E0C6E48 !devobj 0x92C5ACD0 IRP_MJ_POWER, Minor 0x2 IRP 0x95ACCF00 3274: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3275: FxPowerIdleMachine::InDxIoIncrement - WDFDEVICE 701FF620 idle (in Dx) not sending io present event (already sent) 3276: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6E0C6E48 !devobj 0x92C5ACD0 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3277: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3278: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6E0C6E48 !devobj 0x92C5ACD0 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3279: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3280: FxPowerIdleMachine::InDxIoIncrement - WDFDEVICE 701FF620 idle (in Dx) not sending io present event (already sent) 3281: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3282: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D3C1748 !devobj 0x91F39030 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState 3283: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6E0C6E48 !devobj 0x92C5ACD0 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState 3284: FxPkgPnp::Dispatch - WDFDEVICE 0x762E57C0 !devobj 0x89CB5A48 IRP_MJ_POWER, Minor 0x2 IRP 0x9709CF00 3285: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x762E57C0 !devobj 0x89CB5A48 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3286: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x762E57C0 !devobj 0x89CB5A48 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3287: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3288: FxPowerIdleMachine::InDxIoIncrement - WDFDEVICE 701FF620 idle (in Dx) not sending io present event (already sent) 3289: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3290: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x762E57C0 !devobj 0x89CB5A48 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState 3291: FxPkgPnp::Dispatch - WDFDEVICE 0x6D398480 !devobj 0x84382AD8 IRP_MJ_POWER, Minor 0x2 IRP 0x993F8F00 3292: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D398480 !devobj 0x84382AD8 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3293: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D398480 !devobj 0x84382AD8 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3294: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3295: FxPowerIdleMachine::InDxIoIncrement - WDFDEVICE 701FF620 idle (in Dx) not sending io present event (already sent) 3296: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3297: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D398480 !devobj 0x84382AD8 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState 3298: FxPkgPnp::Dispatch - WDFDEVICE 0x6D39E210 !devobj 0x92C56C50 IRP_MJ_POWER, Minor 0x2 IRP 0x993DAF00 3299: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D39E210 !devobj 0x92C56C50 entering Power State WdfDevStatePowerCheckDeviceType from WdfDevStatePowerDx 3300: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D39E210 !devobj 0x92C56C50 entering Power State WdfDevStatePowerCheckParentState from WdfDevStatePowerCheckDeviceType 3301: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDxIoIncrement from FxIdleInDx 3302: FxPowerIdleMachine::InDxIoIncrement - WDFDEVICE 701FF620 idle (in Dx) not sending io present event (already sent) 3303: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x701FF620 !devobj 0x92C43C50 entering power idle state FxIdleInDx from FxIdleInDxIoIncrement 3304: FxPkgPnp::PowerEnterNewState - WDFDEVICE 0x6D39E210 !devobj 0x92C56C50 entering Power State WdfDevStatePowerWaitForParent from WdfDevStatePowerCheckParentState Tag: Hypervisor-based transport for KD Tag: 102775
  - 9
    - IRP_URB_DOUBLE_SUBMIT problem Hi, I am getting a crash in my driver in long hour tests. Every time the bugcheck (0xFE) identifies the problem as IRP_URB_DOUBLE_SUBMIT. The documentation of this says : The caller has submitted an irp that is already pending in the USB bus driver. However nowhere in my driver I am re-using an IRP ! Every time I allocate an IRP and destroy it in the completion. I assume that IoAllocateIrp will every time give me a fresh IRP and so same IRP will never be submitted to USB subsystem. I am therefore perplexed why it would happen so. Is it that the bugcheck can also occur for some other case than irp resubmitting? I also observe that when I try to get the details of the IRP in question, I get "Could not read device object or _DEVICE_OBJECT not found" message for the device object associated with the IRP. Any pointers will be great appreciated. Thanks and Regards, Abhijit Tag: Hypervisor-based transport for KD Tag: 102772
  - 10
    - NDIS IM Driver and Custom Filter Class Hi, I have developed an IM NDIS driver. There are 3 types of filter classes failover, loadbalance and scheduler. Is it possible to make new custom filter class. which resides above from scheduler class? Please tell me how can I do it? -- With regards thanks Anand Choubey Tag: Hypervisor-based transport for KD Tag: 102771
  - 11
    - How to get a tcp/ucp port in im driver without copying all packet content? In my intermediate driver (ndis5.1), i just want to check each tcp/udp packet's port number. I check the packet in the way that copy each packet content to my own buffer and then check the port number. I want to know is there any way to know the tcp/ucp packet port number without copying the content each time? Or the copy procedure is the must be....? Thanks for your advice! Tag: Hypervisor-based transport for KD Tag: 102767
  - 12
    - Power management problem in 5.1 NDIS miniport driver Hi, all I'm currently implementing the power management logic in the NDIS miniport driver of our PCI wireless card. We would like our driver to make sure the card is in D0 state during the driver initialization. But there seems to be a problem. Obviously, I can't access our PCI configuration space in DriverEntry, since at this stage the driver doesn't even know what devce it's going to work with, let alone having its configuration space mapped. I thought I'd take care of the transition to D0 in our MiniportInitialize callback, but the thing is this callback is not even called when the card happens to be in D3 state upon drier initialization. I used a debugger to see what other NDIS drivers do. I've found out that, for instance, when the DriverEntry function of RealTek 8139 card's driver (also NDIS 5.1. based) is called, the device is always in D3 state (I used !pci command of WinDbg to examine the card's PCI configuration space). Then I set breakpoints on every callback function registered by the call to NdisMRegisterMiniport from DriverEntry. The first callback to be called was InitializeHandler and, somehow, by the time it was called the card's power state had already been changed to D0! I wonder what and how caused this to happen, as this is precisely what I need my driver to be capable of doing. I do believe I could achieve this in a NDIS 6.0 driver - probably, providing an optional handler for AddDevice IRP would give me an appropriate context for writing to the configuration space causing the device to switch to D0. But I really have no idea how this could be done in an NDIS 5.1 driver. Yet, this is precisely what the RealTek 8139 driver manages to pull off. Any help on the issue will be highly appreciated. Regards, Alexey Tag: Hypervisor-based transport for KD Tag: 102762
  - 13
    - pci slot (device) number Hi, in the past my (WDM based) driver needed to extract the pci bus number and the slot (device - i.e the location on the bus) number for a device. this was easy to do using the HalGetBusData routines. nowdays, these routine are obsolete and my new driver is WDF based. though, i still need to get these numbers (bus & slot(device) numbers) and having trouble with the device number. using the WDF routine "WdfDeviceAllocAndQueryProperty" i'm able to retrieve the bus number easily using the "DevicePropertyBusNumber" prperty. BUT, extracting the slot(device) number is something i cant figure out (i can only get it by using the WdfDeviceAllocAndQueryProperty routine with a DevicePropertyLocationInformation attribute but then i have to parse a string which not seems like a good way). so, my question is how is the best way to replace the HalGetBusData routine for extracting a devices slot(device) number. can i somehoe use the PCI_SLOT_NUMBER structure along with "IRP_MN_READ_CONFIG" ? thanks a lot, kobi. Tag: Hypervisor-based transport for KD Tag: 102760
  - 14
    - Bulk transfer with UVC driver Hi, I am developing an UVC device. In order to increase the transfer rate I'd like to use a bulk endpoint for the video transfer. I can successfully enumerate and create a filter graph with my device, but as soon as I start the graph, my machine reboots. Note that this does not happen if I use an isochronous endpoint. The blue screen error that shows up is 0x0000007F with the first parameter 0x00000000 (division by zero). Is bulk transfer supported for the current xp sp2 usbvideo.sys driver? Is this a known bug? What's the best setup to debug this situation? Any other hint? Thanks AT Tag: Hypervisor-based transport for KD Tag: 102752
  - 15
    - windbg problem - still showing old structures hi all, I modified a DDK sample ( many structures changed, but same names ) and when i use windbg, it still shows the old structure fields! ( outdated stale info ). since, i was not sure from where windbg picks up this stale symbol info, I renamed most of the stuff, deleted many leftover intermediate files ( like .OBJ ) from the original DDK sample , still WINDBG showing the old structure fields. Has anybody faced this and how to fix this. All trivial things were tried, like !sym noisy and .reload commands. The newly built PDB file is only loaded. Able to set BPs, etc * the DDK sample in question is network E100BEX * latest windbg version 6.8.0004.0. About box also shows 5.0 ( build 2600.xpsp_sp2_gdr.....:sp2 ) * tried both new DDK versions , build 6000 & 6001 * target VISTA and host xp-sp2 thro 1394 * local symbols any clues? thx ugk Tag: Hypervisor-based transport for KD Tag: 102749
  - 16
    - How to disable an intermediate driver? When I open the networking connections and check one connection's properties, i could see the im driver i made was listed in the items list. There is a check box on the left of each item, if i uncheck the box, which means that the item is to be disabled. So the question is What a "disable" means in this circumstance? Does it means that the corresponding service will be stopped, or the driver will be unload, or any other else? I just want to know... The other question is that how can i write an application to control the status of this? That is through the code to contorl the "enable" or "disable". I searched google but could not find some information about it. Thank you for any advice... Tag: Hypervisor-based transport for KD Tag: 102746
  - 17
    - Tracing using the WPP I plan to add the tracing capability to the driver using the WPP. According to Microsoft's document, the performance impact to the driver is very low. I would like to know if it is true or not from people here. If you have ever added this feature in your driver, can you feedback your opionions. Thanks. Tag: Hypervisor-based transport for KD Tag: 102741
  - 18
    - TCP Stop Working I have an ndis miniport driver that I've developed. ARP, TCP, ICMP, etc, all seem to work fine. But when I run an extened test that sends data over a socket for about 10 minutes straight, TCP stops working on the entire system. Other protcols are still working, because ping works just fine. It's not just my miniport interface that doesn't work. I can't get TCP to work on any network interface. When I try to run ipconfig I get the following error "The application failed to initialize properly (0xc0000142). Click on OK to terminate the application." I also tried running Ethereal after the error occurred, and it can't even find any interfaces to bind to. I have driver verifier turned on my driver, and no errors were detected. Has anyone ran into this condition before? How do you debug a system in this state? Thanks, Michael Tag: Hypervisor-based transport for KD Tag: 102740
  - 19
    - Driver to work around WriteFile access denied issue in Vista I wrote a program, several years old, which uses WriteFile to write to sector 0 on compact flash disks. As has been noted in other threads this fails under Vista with an access denied message. (I haven't seen this change noted in MSDN documentation.) The work around given in the threads is to write a driver to do the write. Since this is an apparent common problem and I have never before written a driver myself, I was hoping there might be some example source code or hopefully an installable driver already avaialble. Does anybody know of any? Thanks in advance. Tag: Hypervisor-based transport for KD Tag: 102739
  - 20
    - PtSendComplete Adapter=NULL My intermediate driver is crashing on random occations at PtSendComplete() it seem like the Adapter become NULL when the driver call NdisMSendComplete( TransportHandle, OriginalPacket, Status ); . However the Adapter is always valid until NdisMSendComplete get call. below is my seudocode: VOID PtSendComplete(IN NDIS_HANDLE ProtocolBindingContext, IN PNDIS_PACKET Packet, IN NDIS_STATUS Status ) { -passed lower MP adapter context -get fully iniialized context -complete the original packet back to the higher layer -get the original packet, passed down from the transport -deallocate the chained buffers -Check if this is the duplicate packet -recyle the resources if done witht the copy of the packet -complete the original packet if it came from an upper transport -need to use the original send adapter to pass the completed packet back to the one that sent it. TransportHandle = OriginalAdapter->IMNdisHandle; NdisInterlockedIncrement(&Adapter->PtSendCompleteCount); ===>invalid handle happend here.<=== NdisMSendComplete( TransportHandle, OriginalPacket, Status ); } If I have a condition to check for NULL adapter, what will it happend if it NULL? is this become memory leak? Why is the adapter become NULL in the middle of the process? how do I avoid the Adapter become NULL so it not going to BSOD? Thanks Tag: Hypervisor-based transport for KD Tag: 102738
  - 21
    - How do you make a WDF driver create .Raw & .Translated resources? I'm trying to convert a legacy device driver, which was created with BlueWater's DriverWizard, to WDF. The legacy driver creates MyDriverName.Raw & MyDriverName.Translated resources under MACHINE\HARDWARE\RESOURCEMAP\PnP Manager\PnpManager, but the WDF driver does not. How do I make the WDF driver create these resources? /Russ Tag: Hypervisor-based transport for KD Tag: 102735
  - 22
    - Dispatch and Completion routine synchronisation Dear all, I am a little confused because I keep finding contradicting information about this issue. In a dispatch routine, I set a completion routine and then forward the Irp to the lower driver. Something like this: IoSetCompletionRoutine(Irp, CompletionRoutine, &Event, NULL, NULL, NULL); Status = IoCallDriver(...); if (Status == STATUS_PENDING) KeWaitForSingleObject(...); ... Do some processing... IoCompleteRequest(...); return (Status); So, at the moment my completion routine is tiny and looks a little like this: KeSetEvent(...); return (STATUS_MORE_PROCESSING_REQUIRED); Requirements for the completion routine is to just signal an event so my dispatch routine has an opportunity to do some processing. I've looked at lots of sample code, DDK docs and newsgroup postings and I still am not exactly sure what I should do in terms of what I do in the completion routine and what NTSTATUS value I return from the dispatch routine. 1. Should I check for Irp->PendingReturned and call IoMarkIrpPending(Irp) in the completion routine? (The WDK docs imply that I do not because my completion routine is just signalling an event, but other resources state that the synchronicity of the Irp must be propogated). 2. I assume that because I have halted completion processing with STATUS_MORE_PROCESSING_REQUIRED) , I need to call IoCompleteRequest(...) to allow completion processing to continue. 3. What do I return from my dispatch routine? The status of IoCallDriver or Irp->IoStatus.Status? It feels like I have changed the synchronicity of the Irp so it should be Irp->IoStatus.Status. Many thanks in advance! Carl Tag: Hypervisor-based transport for KD Tag: 102730
  - 23
    - IRP_MJ_READ/IRP_MJ_WRITE Buffer Confusion. Dear all, I am confused about which buffer is of interest in read/write dispatch routines (and their completion routines). I understand the differences between direct, buffered and neither buffers. So far, I've concluded that: 1. If Irp->MdlAdress exists, use that. 2. If the lower device object Flags specify DO_BUFFERED_IO then use Irp->SystemAddress.Buffered. 3. If none of the above hold true, then use Irp->UserBuffer. Quite frankly, the above rules makes me nervous because I made them up as I went along! What are the exact rules I should follow? Many thanks in advance! Carl Tag: Hypervisor-based transport for KD Tag: 102729
  - 24
    - AVStream driver show upside-down video for RGB24 format Dear All, I wrote a avstream video capture driver based on the avshws driver sample code. But I found that the FormatRGB24Bpp_Capture structure's bimHeader.biHeight is -D_Y. It's negative value. It will fail to connect the Video renderer in graphedit. If I change it to positive D_Y, then it can render OK. But the video is upside-down. I searched the answer in the web, it looks the negative Height is indicate the bottom-up bitmap. The imageSynth will create a bottom-up frame data to fill into the mapping buffer of the stream queue. But my PCI device can generate only top-down video. And I don't want to use CPU to flip the video data. Is there any way to fix this problem? I ever tried to return my pin's descriptor VideoInfoHeader in the IntersectHandler routine. If can pass the pin connection with negative Height value and the video is correct showing. But the negative Height setting will cause black display in YUY2 format when use AMCAP to preview. Any response is appreciated! Best regards Jerry Pan Tag: Hypervisor-based transport for KD Tag: 102724
  - 25
    - Regarding DTM set up for LAN. Hi, I am doing whql test for LAN device driver (Vista driver). For the DTM set up of LAN, is it Ok if I use one client machine with XP OS and another client machine with Vista OS ? More precisely the NDIS test server will be mchine with XP loaded and the NDIS client machine will be with vista loaded. Is it ok? This is the same setup for DTM setuo of LAN provided in whql help docs . Need immediate help. Rgds, Ram Tag: Hypervisor-based transport for KD Tag: 102717

I envision it as one more KDxxx.DLL which will do send Hypervisor Calls
from within it on target, and a device driver which will do receive Hypervisor
Calls (possibly using Enlightened IO framework) on a host. Possibly this driver
should be a virtual COM port, which will mean no changes to WinDbg/KD proper.

Is it planned by Microsoft? Seems to be a good idea. KD serial port
emulation on a VM is bad idea, since KDCOM cannot use interrupt (it cannot
depend on interrupt framework in the kernel) and just polls the UART in a tight
loop.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Top