I’m not sure if this is a normal behaviour of user-mode drivers in Windows drivers, and I’m having trouble finding about this topic properly on other mailing lists and this one. My problem is that when I’m passing address references to the pointers improperly, my computer suddenly stops and reboots. Is this behaviour normal? or more importantly, is the driver part of the kernel no matter what type of driver it is configured to be in the project?
You shouldn’t see a system crash. Can you explain “when I’m passing address references to the pointers improperly”?
Is this a UMDF driver that you’re writing?
What project?
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Friday, June 13, 2008 1:42 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] user-mode driver reboot behaviour
I’m not sure if this is a normal behaviour of user-mode drivers in Windows drivers, and I’m having trouble finding about this topic properly on other mailing lists and this one. My problem is that when I’m passing address references to the pointers improperly, my computer suddenly stops and reboots. Is this behaviour normal? or more importantly, is the driver part of the kernel no matter what type of driver it is configured to be in the project?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Hi Peter, first of all, thanks for your quick reply.
What I meant by “when I’m passing address references to the pointer improperly” really means when I haven’t allocated memory to a specific pointer, hence having a bad pointer somewhere that could be causing havoc. I’m not 100% sure if I’m using a UMDF driver, but I think I am. More specifically, I’m trying to write a customized printer driver for my project.
First of all, if you have read my previous questions already, I apologize in advance
about the lack of details as well as the organizatio on the reboot problem as well as the inappropriate DDI Hooks callback problems that I’m having trouble with. Here is the full description of my problem and my efforts on addressing the problem so far:
Basically, my goal right now is to reproduce the DDI hook callbacks when I print a document after installing a custom built printer driver, which is basically a shell right now that I’m trying to obtain the appropriate order of driver DDI calls. According to the MSDN WDK documentation to my understanding, the following is the order of appropriate DDI callbacks that I should be seeing on my debug output/logfile:
Expected order of DDI hooks calls from printer driver:
- DllMain
- DrvEnableDriver
- DrvEnablePDEV
- DrvCompletePDEV
- DrvEnableSurface
- DrvStartDoc
// Specific DDI hooks needed to draw the document - DrvEndDoc
- DrvDisableSurface
- DrvDisablePDEV
- DrvDisableDriver
I have implemented minimally all the callbacks without the specific DDI hooks that are responsible for the drawing on the output document being implemented (http://rafb.net/p/aFCP6m32.html, please assume that the needed header files for the driver are included as I don’t want to overburden you with details). However, I am stopping to obtain debug output at DrvDisablePDEV, without having DrvDisableDriver even invoked (here is the logfile in case if you’re interested or if it helps: http://rafb.net/p/3BYSFU19.html). I’m not sure about first of all if it’s my faulty implementations of the driver callbacks (although I have tried to follow the examples as diligently as possible on my part), or if there is something missing in the implementations that caused the callbacks that are called to be different from what I expect. Pointers to perhaps fundamentally what’s possibly wrong with what I did on the driver would be very helpful. Although from what I’ve read on MSDN documentation that the ui component of a printer driver is independent from the driver in terms of operation, how likely is it that the return objects/values of some unimplemented ui functions to be causing unexpected behaviours in the driver callbacks? It would be much appreciated if I could be shown in another direction on how this could be affecting the driver behaviour.
On a second note, it would be much appreciated to receive a possible get-around on using EngXXX GDI functions in the driver callback implementation. According to Steven Friedl’s UnixWiz Techtips on converting Win32 kernel-mode printer drivers to user-mode (http://www.unixwiz.net/techtips/win32-pdriver-ktou.html), specifically in the section “Re-implement kernel-only DDI functions”, the support functions given by Microsoft Windows Driver Kit, EngXXX(…), are generally available with the listed exceptions in that section, Microsoft suggests that true user-mode functions are to be used. I have done everything that Friedl has logged on how he gotten rid of the conversion problem to get rid of a system reboot after a print trial, but when I reuse the EngXXX(…) functions again, I have gotten myself into a system reboot problem again that disappeared when the EngXXX(…) functions are gone. I’m lost on how to implement real user-mode functions as Microsoft recommended. For example, does it mean that I should use a CPalette object in place of EngCreatePalette and EngDeletePalette, Surface class object in place of EngCreateDeviceSurface, EngAssociateSurface, and EngDeleteSurface? I originally reused those EngXXX(…) again b/c I couldn’t think of any workable alternatives when I was reading WDK documentation on MSDN. It would be much appreciated to learn if I’m approaching the right direction if I attempt those user-mode methods to return the objects as return values for the callbacks to get them properly implemented to receive the DDI calls that I’m looking for.
Thank you very much for taking the time to read my question. I tried to shorten this entry as much as possible while providing as much relevant details as possible about my problem to help other developers as well regarding this issue in the future. Please don’t hesitate to ask for more details (for example, some ui code as I didn’t post it right now as I don’t think it’s relevant at this point) as I would provide them as promptly as possible.
I apologize for the additional unnecessary post on this board, but I found out that I have forgotten to enclose my implementation on DrvEnableSurface and DrvDisableSurface so far. (http://rafb.net/p/vCOUWV54.html) shows the link and I think they are very relevant to what I’m experiencing so far. I’m also working diligently on using other Microsoft Visual Studio API functions to get around the EngXXX functions right now.
xxxxx@hotmail.com wrote:
First of all, if you have read my previous questions already, I apologize in advance
about the lack of details as well as the organizatio on the reboot problem as well as the inappropriate DDI Hooks callback problems that I’m having trouble with. Here is the full description of my problem and my efforts on addressing the problem so far:
I’m sorry, but I’ve tried to read through your post in detail, and I do
not see any description of your problem.
Basically, my goal right now is to reproduce the DDI hook callbacks when I print a document after installing a custom built printer driver, which is basically a shell right now that I’m trying to obtain the appropriate order of driver DDI calls. According to the MSDN WDK documentation to my understanding, the following is the order of appropriate DDI callbacks that I should be seeing on my debug output/logfile:
Expected order of DDI hooks calls from printer driver:
- DllMain
- DrvEnableDriver
- DrvEnablePDEV
- DrvCompletePDEV
- DrvEnableSurface
- DrvStartDoc
// Specific DDI hooks needed to draw the document- DrvEndDoc
- DrvDisableSurface
- DrvDisablePDEV
- DrvDisableDriver
I have implemented minimally all the callbacks without the specific DDI hooks that are responsible for the drawing on the output document being implemented (http://rafb.net/p/aFCP6m32.html, please assume that the needed header files for the driver are included as I don’t want to overburden you with details).
Your rafb.net links come up 404. I don’t know whether it is a timeout
or a size limitation.
Your HOOK flags say that you are implementing most of the drawing APIs,
but your comment implies that you haven’t actually supplied routines for
them. Is that true?
Where does the crash happen?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Thanks for replying to my question. I’m not sure what happened to my question as in retrospect on reviewing the question, some materials don’t appear to be posted properly. I’m pasting another version of my original question as well as the information on the printouts, summary here: http://www.mediafire.com/?4dndk5vmggn (hopefully you and other readers can see it).
My situation right now is that I haven’t implemented any of the drawing DDI Hooks. I have only implemented (or attempted to implement the following: DllMain, DrvQueryDriverInfo, DrvEnableDriver, DrvEnablePDEV, DrvCompletePDEV, DrvEnableSurface, DrvStartDoc, DrvStartPage, DrvSendPage, DrvEndDoc, DrvDisableSurface, DrvDisablePDEV, DrvDisableDriver. The crash appears to happen at DrvDisablePDEV, with the DDI calls in between DrvEnablePDEV and DrvDisablePDEV not being called.
Right now, I’m working on a change in the EngXXX functions to perhaps the user-mode functions to hopefully at least fix the sudden reboot problem that it’s confusing itself with a kernel mode driver, even though by checking the driver in the dump mode in windbg that it’s a user-mode driver, and I have gone through Friedl’s link to ensure that I’m indeed using a user-mode driver.
xxxxx@hotmail.com wrote:
My situation right now is that I haven’t implemented any of the drawing DDI Hooks. I have only implemented (or attempted to implement the following: DllMain, DrvQueryDriverInfo, DrvEnableDriver, DrvEnablePDEV, DrvCompletePDEV, DrvEnableSurface, DrvStartDoc, DrvStartPage, DrvSendPage, DrvEndDoc, DrvDisableSurface, DrvDisablePDEV, DrvDisableDriver. The crash appears to happen at DrvDisablePDEV, with the DDI calls in between DrvEnablePDEV and DrvDisablePDEV not being called.
Actually, you’d have to say that the crash appears to be AFTER
DrvDisablePDEV. The log shows that the final message in DrvDisablePDEV
came out correctly.
So, have you not hooked up a debugger to find out exactly where this
crashes?
Right now, I’m working on a change in the EngXXX functions to perhaps the user-mode functions to hopefully at least fix the sudden reboot problem that it’s confusing itself with a kernel mode driver, even though by checking the driver in the dump mode in windbg that it’s a user-mode driver, and I have gone through Friedl’s link to ensure that I’m indeed using a user-mode driver.
Please rest assured that no operating system component will be confused
about whether your driver is user-mode code or kernel-mode code.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I haven’t hooked up windbg to check where I’m crashing yet (actually in the process of doing so). As of currently, I’ve been using DebugView and log files to check where I’m obtaining the last DDI call, which is perhaps a very bad way to debug where I’m crashing.
After doing some more code tweaking, I found out that the ui component of my printer driver is not calling the right functions/returning the appropriate types/values to the GDI Rendering Engine, which probably caused some specific driver ddi hook not being called. So I guess this problem has been solved as long as I don’t fall into the kernel mode trap again.