- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: How to debug a memory resident driver written ...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2006 09:19 AM
тАО04-19-2006 09:19 AM
How to debug a memory resident driver written in Macro32?
I am trying to debug a memory resident driver written in macro32. Its loading Ok using SYSMAN but crashing when doing SYSMAN IO CONNECT.
Note:Please also see the attached Clue Crash-01.txt file for more information.
Best Regards!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2006 11:44 AM
тАО04-19-2006 11:44 AM
Re: How to debug a memory resident driver written in Macro32?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2006 12:12 PM
тАО04-19-2006 12:12 PM
Re: How to debug a memory resident driver written in Macro32?
The bugcheck code is correct, your stack is invalid. The stack address in the dump is in S0 space, it should be in P1 space.
Best guess is some of your driver code has corrupted a stack frame, which has resulted in restoring a bogus stack pointer address on return.
Tricky to debug. I'd start with a careful code inspection of the IO CONNECT path - look at argument lists in and out, and also at stores to stack local storage. Perhaps there's an assumption about the size of a data structure that's been violated?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2006 06:38 PM
тАО04-19-2006 06:38 PM
Re: How to debug a memory resident driver written in Macro32?
try SDA> CLUE CALL to get a summary of the call frames. Or SDA> SHOW CALL and a couple of SHOW CALL/NEXT
The KSP - as saved in the HWPCB - is reported as FFFFFFFF.FFFFFFC0 - clearly invalid (if that saved value is true).
You may want to look around on the real KERNEL stack for a longword of FFFFFFC0. You can find the stack address/limits with:
SDA> EXA ctl$aq_stack;20 ! bottom of stacks
SDA> EXA ctl$aq_stacklim;20 ! top of stacks
The first quadwords shown are the allowed range of the KERNEL stack.
There is also a return address in R26, try
SDA> EXA/INS 7FFA1ED0-20;30
You need to try to determine the context of the routine being executed immediately before the crash. Sometime the register contents are helpful:
SDA> FORMAT 80D47700
Try to provide the data as an attached .TXT file and we'll see what can be done next...
Is this a new driver, did it ever work before ?
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-19-2006 09:32 PM
тАО04-19-2006 09:32 PM
Re: How to debug a memory resident driver written in Macro32?
KSP = FFFFFFFF.FFFFFFC0
I am trying to remember if this value is wholly trustworthy, or whether the console has stepped on it by the time we get to see this content. I think it is good data, but in this context utterly invalid as an SP.
How do we get to __RELEASE_KERNEL_SERVICE: ? It does not appear to be through EXE$CMODKRNL_C.
Note the following comments on the previous instructions.
R5 = 00000000.00000088
R7 = 00000000.00000038
R22 = 00000000.00000000
EXE$CMODKRNL_C+0019C: LDA R22,#X0800(R31) < Put 800 into R22
EXE$CMODKRNL_C+001A0: BIS R7,R31,SP < zap stack pointer
EXE$CMODKRNL_C+001A4: AND R5,R22,R22 < 800 AND 88 do not make zero
EXE$CMODKRNL_C+001A8: BEQ R22,#X000001 < branch because R22 is zero
EXE$CMODKRNL_C+001AC: BSR R4,#X000298 < not executed
__RELEASE_KERNEL_SERVICE: STQ R6,#X0030(SP) < die horribly. BUT...
the SP is inconsistent with having been written at EXE$CMODKRNL_C+001A0, and other register contents are also inconsistent with executing that code stream.
The implication is that there is a branch or jump, either to EXE$CMODKRNL_C+001A8:, or to __RELEASE_KERNEL_SERVICE: somewhere else, either in EXE$CMODKRNL_C, or in the loaded driver.
You probably need to learn, and use, Xdelta.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-20-2006 12:02 AM
тАО04-20-2006 12:02 AM
Re: How to debug a memory resident driver written in Macro32?
the code, which has reported the KRNLSTAKNV crash, is the system service completion code (SERVICE_EXIT), which gets executed, when a system service completes. And the code stream all makes sense...
R7 is supposed to hold the inner mode SP
AND R5, R22, R22 will return R22=0 (with R5=88 and R22=800 to begin with)
so the branch is taken and we crash on the STQ instruction.
I'm pretty confident, that CLUE CALL will show more information and allow to follow the code flow until the time of the crash.
Let's wait and see...
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-20-2006 01:40 AM
тАО04-20-2006 01:40 AM
Re: How to debug a memory resident driver written in Macro32?
CLUE tells us that R7 contains 00000000.00000038
The KSP in the Process HWPCB is FFFFFFFF.FFFFFFC0
The BIS R7,R31,SP will copy the entire content of R7 to the SP, and I cannot see at this moment how we come by the 78 difference.
The STQ R6,#X0030(SP) will try to write to SP+30, which will be either 00000068 or FFFFFFF0 depending on whether the KSP value in the HWPCB is a valid representation of the KSP at the time of the STQ, or has been modified by the console. (Maybe R7 has been changed instead!)
Perhaps I have forgotten too much in the last few years, but this looks to me as though the value in R7 is not what it should have been.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-20-2006 07:57 AM
тАО04-20-2006 07:57 AM
Re: How to debug a memory resident driver written in Macro32?
Please do find the attached SDA text output's from the original source. I have revoked my changes and create a new build from the original code. This driver is a step-2 driver and was running flawlessly on 6.2-1H3 and 7.0.
Regards!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-20-2006 09:44 AM
тАО04-20-2006 09:44 AM
Re: How to debug a memory resident driver written in Macro32?
This could be difficult to trace without the listings for this driver. What is the label you have at PRADCH$PRDRIVER+05C68, and where in your driver do you invoke that label as a the destination of a jump or branch ?
There is a good chance that immediately prior to PRADCH$PRDRIVER+05B90 you have a JSR R26(R26) to that label. If so, please look carefully at why that JSR is taken, and consider what could cause it.
In any case, please show us as much of the code as you can, especially around that area, either from the listing file, or from SDA.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-20-2006 11:22 AM
тАО04-20-2006 11:22 AM
Re: How to debug a memory resident driver written in Macro32?
Check the attached crash dump analysis.
Regards!