Overflow of somekind

NTDEV
1

Hi,

I have a crash that it giving me grief. EIP points to NULL so I suspect
an overflow somewhere and I do not have a stack trace. Now the problem
I have is that I have run Bounds Checker through it and Intel Thread
Checker and none of them show any obvious problems related to the crash.
It only happens on hyper-threaded and multi-processor machines which
also give me a clue on some kind of synchronisation problem (but Intel
Thread Checker didn’t find any). Anyone got any idea on how best to
approach this bug?

Thanks
Ceri

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: 12 October 2004 09:36
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Losing Received Data?

You could always use VTune (or some other performance profiling tool) to
figure out what takes time in your driver (or someone elses driver).

Debug output that doesn’t actually print anything (if you use levels for
instance) will still take a fair amount of time, simply because of
argument
passing and calling the debut output function.

But to achieve something like 60% CPU performance on a reasonably modern
processor, you need to actually do quite a lot. Why not break into the
system a few times and see where it’s at. (Press CTRL-Break and check
the
stack to see what’s going on). You should have a hit in whatever it is
that
takes a lot of time every other time. This is called “poor mans
profiling”,
and it actually works much better than you’d think.

–
Mats

xxxxx@lists.osr.com wrote on 10/12/2004 08:55:25 AM:

Hi again,

I noticed that when the driver was running under the debugger the
system load was very high, the red part of the graph indicating
kernel load was hovering around 60% when the driver was loaded and
with no serial comms taking place, I have no idea why. So I tried
the same (debug) version of the driver in the non-debug version of
W2K to remove any issues caused by the debugger and it’s serial
comms, system load was the same but the dial-up connection
succeeded! so I think it is a performance issue rather than a logic
issue.

I don’t know why the load should be so high, there are no threads in
the driver and as far as I am aware it should just be sitting there
doing nothing, you probably know better.

My next test will be to see what the load is with the free version
of the driver.

Thanks for the suggestions regarding using a test app to thrash the
comms, I may still need to resort to that but for time being I think
I will need to track down this load problem.

As usual, any suggestions greatly appreciated.

Thanks

Alasdair

-----Original Message-----
From: Alasdair Tompson (external)
[mailto:xxxxx@t-mobile.co.uk]
Sent: 11 October 2004 16:58
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Losing Received Data?

Thanks Mats and Joseph,
Good idea, I am going home now so I’ll look into that tomorrow.
Alasdair

> -----Original Message-----
> From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
> Sent: 11 October 2004 16:55
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Losing Received Data?
>
>
>
>
>
>
>
> > PS. You can probably write a simple usermode program
> > to run on the other side and generate this problem…
> > just open the comm port and write a pretty good burst
> > of data.
>
> This is a good idea. Instead of using the phone (which of
> course is the ultimate target), use a PC with either standard
> of custom software on it.
> >
> > You can probably also do it using hyperterms file
> > transfer facility (ZModem/Xmodem I think it supports
> > at least one of these.)
> >
> > Typing in hyperterm isn’t a good test since even with
> > all the debugging, the computer is still probably faster
> > than you are.
>
> I don’t know if Hyperterm supports it, but definitely some
> other terminal programs (TeraTerm comes to mind, but I’m
> unsure if this feature is
> included) support logging and transmitting of text-files
> (ASCII transfer mode). So buiild a text-file with a heap of
> text that you can identify if it’s been transmitted correctly
> at the other end, with varying lenghts and “no protocol”
> (because using a protocol just confuses the issue) and send
> some data across.
>
> If you write a little test-app, then one test method should
> be to transmit a file and compare at the other end (so you
> start the compare first, then start the transmit, and the
> test-app shows which lines come across badly). That way, you
> can test different patterns, sizes, etc, etc, and change the
> test-setup without having to do too much programming.
>
> Writing custom test-tools is a big part of device drivers,
> because you need to be able to do “directed testing”, e.g.
> testing special cases without hitting some other stuff that
> is currently not working, etc, etc.
>
>
> –
> Mats
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@t-mobile.co.uk To unsubscribe send a blank
> email to xxxxx@lists.osr.com
>

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have
received this email in error please notify the sender immediately
and delete this email from your system without copying or
disseminating it or placing any reliance upon its contents. We
cannot accept liability for any breaches of confidence arising
through use of email. Any opinions expressed in this email
(including attachments) are those of the author and do not
necessarily reflect our opinions. We will not accept responsibility
for any commitments made by our employees outside the scope of our
business. We do not warrant the accuracy or completeness of such
information.

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

You are currently subscribed to ntdev as:
xxxxx@t-mobile.co.uk

To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have
received this email in error please notify the sender immediately
and delete this email from your system without copying or
disseminating it or placing any reliance upon its contents. We
cannot accept liability for any breaches of confidence arising
through use of email. Any opinions expressed in this email
(including attachments) are those of the author and do not
necessarily reflect our opinions. We will not accept responsibility
for any commitments made by our employees outside the scope of our
business. We do not warrant the accuracy or completeness of such
information.

ForwardSourceID:NT00005356

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

2

Bugs with inter-thread synchronization are usually found by core re-read
and not by debugging. They are very hard, and are better to be avoided then
fixed.

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

----- Original Message -----
From: “Ceri Coburn”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 06, 2004 6:02 PM
Subject: [ntdev] Overflow of somekind

Hi,

I have a crash that it giving me grief. EIP points to NULL so I suspect
an overflow somewhere and I do not have a stack trace. Now the problem
I have is that I have run Bounds Checker through it and Intel Thread
Checker and none of them show any obvious problems related to the crash.
It only happens on hyper-threaded and multi-processor machines which
also give me a clue on some kind of synchronisation problem (but Intel
Thread Checker didn’t find any). Anyone got any idea on how best to
approach this bug?

Thanks
Ceri

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: 12 October 2004 09:36
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Losing Received Data?

You could always use VTune (or some other performance profiling tool) to
figure out what takes time in your driver (or someone elses driver).

Debug output that doesn’t actually print anything (if you use levels for
instance) will still take a fair amount of time, simply because of
argument
passing and calling the debut output function.

But to achieve something like 60% CPU performance on a reasonably modern
processor, you need to actually do quite a lot. Why not break into the
system a few times and see where it’s at. (Press CTRL-Break and check
the
stack to see what’s going on). You should have a hit in whatever it is
that
takes a lot of time every other time. This is called “poor mans
profiling”,
and it actually works much better than you’d think.

–
Mats

xxxxx@lists.osr.com wrote on 10/12/2004 08:55:25 AM:

> Hi again,
>
> I noticed that when the driver was running under the debugger the
> system load was very high, the red part of the graph indicating
> kernel load was hovering around 60% when the driver was loaded and
> with no serial comms taking place, I have no idea why. So I tried
> the same (debug) version of the driver in the non-debug version of
> W2K to remove any issues caused by the debugger and it’s serial
> comms, system load was the same but the dial-up connection
> succeeded! so I think it is a performance issue rather than a logic
issue.
>
> I don’t know why the load should be so high, there are no threads in
> the driver and as far as I am aware it should just be sitting there
> doing nothing, you probably know better.
>
> My next test will be to see what the load is with the free version
> of the driver.
>
> Thanks for the suggestions regarding using a test app to thrash the
> comms, I may still need to resort to that but for time being I think
> I will need to track down this load problem.
>
> As usual, any suggestions greatly appreciated.
>
> Thanks
>
> Alasdair
>
>
> -----Original Message-----
> From: Alasdair Tompson (external)
[mailto:xxxxx@t-mobile.co.uk]
> Sent: 11 October 2004 16:58
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Losing Received Data?

> Thanks Mats and Joseph,
> Good idea, I am going home now so I’ll look into that tomorrow.
> Alasdair
>
> > -----Original Message-----
> > From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
> > Sent: 11 October 2004 16:55
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Losing Received Data?
> >
> >
> >
> >
> >
> >
> >
> > > PS. You can probably write a simple usermode program
> > > to run on the other side and generate this problem…
> > > just open the comm port and write a pretty good burst
> > > of data.
> >
> > This is a good idea. Instead of using the phone (which of
> > course is the ultimate target), use a PC with either standard
> > of custom software on it.
> > >
> > > You can probably also do it using hyperterms file
> > > transfer facility (ZModem/Xmodem I think it supports
> > > at least one of these.)
> > >
> > > Typing in hyperterm isn’t a good test since even with
> > > all the debugging, the computer is still probably faster
> > > than you are.
> >
> > I don’t know if Hyperterm supports it, but definitely some
> > other terminal programs (TeraTerm comes to mind, but I’m
> > unsure if this feature is
> > included) support logging and transmitting of text-files
> > (ASCII transfer mode). So buiild a text-file with a heap of
> > text that you can identify if it’s been transmitted correctly
> > at the other end, with varying lenghts and “no protocol”
> > (because using a protocol just confuses the issue) and send
> > some data across.
> >
> > If you write a little test-app, then one test method should
> > be to transmit a file and compare at the other end (so you
> > start the compare first, then start the transmit, and the
> > test-app shows which lines come across badly). That way, you
> > can test different patterns, sizes, etc, etc, and change the
> > test-setup without having to do too much programming.
> >
> > Writing custom test-tools is a big part of device drivers,
> > because you need to be able to do “directed testing”, e.g.
> > testing special cases without hitting some other stuff that
> > is currently not working, etc, etc.
> >
> >
> > –
> > Mats
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@t-mobile.co.uk To unsubscribe send a blank
> > email to xxxxx@lists.osr.com
> >
>

> NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential. If you have
> received this email in error please notify the sender immediately
> and delete this email from your system without copying or
> disseminating it or placing any reliance upon its contents. We
> cannot accept liability for any breaches of confidence arising
> through use of email. Any opinions expressed in this email
> (including attachments) are those of the author and do not
> necessarily reflect our opinions. We will not accept responsibility
> for any commitments made by our employees outside the scope of our
> business. We do not warrant the accuracy or completeness of such
information.
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@t-mobile.co.uk

> To unsubscribe send a blank email to xxxxx@lists.osr.com
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

> NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential. If you have
> received this email in error please notify the sender immediately
> and delete this email from your system without copying or
> disseminating it or placing any reliance upon its contents. We
> cannot accept liability for any breaches of confidence arising
> through use of email. Any opinions expressed in this email
> (including attachments) are those of the author and do not
> necessarily reflect our opinions. We will not accept responsibility
> for any commitments made by our employees outside the scope of our
> business. We do not warrant the accuracy or completeness of such
information.
>
> ForwardSourceID:NT00005356

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

I had a feeling that would be the answer to my problem.

Thanks anyway

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: 06 December 2004 19:12
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Overflow of somekind

Bugs with inter-thread synchronization are usually found by core
re-read
and not by debugging. They are very hard, and are better to be avoided
then
fixed.

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

----- Original Message -----
From: “Ceri Coburn”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 06, 2004 6:02 PM
Subject: [ntdev] Overflow of somekind

Hi,

I have a crash that it giving me grief. EIP points to NULL so I suspect
an overflow somewhere and I do not have a stack trace. Now the problem
I have is that I have run Bounds Checker through it and Intel Thread
Checker and none of them show any obvious problems related to the crash.
It only happens on hyper-threaded and multi-processor machines which
also give me a clue on some kind of synchronisation problem (but Intel
Thread Checker didn’t find any). Anyone got any idea on how best to
approach this bug?

Thanks
Ceri

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
Sent: 12 October 2004 09:36
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Losing Received Data?

You could always use VTune (or some other performance profiling tool) to
figure out what takes time in your driver (or someone elses driver).

Debug output that doesn’t actually print anything (if you use levels for
instance) will still take a fair amount of time, simply because of
argument
passing and calling the debut output function.

But to achieve something like 60% CPU performance on a reasonably modern
processor, you need to actually do quite a lot. Why not break into the
system a few times and see where it’s at. (Press CTRL-Break and check
the
stack to see what’s going on). You should have a hit in whatever it is
that
takes a lot of time every other time. This is called “poor mans
profiling”,
and it actually works much better than you’d think.

–
Mats

xxxxx@lists.osr.com wrote on 10/12/2004 08:55:25 AM:

> Hi again,
>
> I noticed that when the driver was running under the debugger the
> system load was very high, the red part of the graph indicating
> kernel load was hovering around 60% when the driver was loaded and
> with no serial comms taking place, I have no idea why. So I tried
> the same (debug) version of the driver in the non-debug version of
> W2K to remove any issues caused by the debugger and it’s serial
> comms, system load was the same but the dial-up connection
> succeeded! so I think it is a performance issue rather than a logic
issue.
>
> I don’t know why the load should be so high, there are no threads in
> the driver and as far as I am aware it should just be sitting there
> doing nothing, you probably know better.
>
> My next test will be to see what the load is with the free version
> of the driver.
>
> Thanks for the suggestions regarding using a test app to thrash the
> comms, I may still need to resort to that but for time being I think
> I will need to track down this load problem.
>
> As usual, any suggestions greatly appreciated.
>
> Thanks
>
> Alasdair
>
>
> -----Original Message-----
> From: Alasdair Tompson (external)
[mailto:xxxxx@t-mobile.co.uk]
> Sent: 11 October 2004 16:58
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Losing Received Data?

> Thanks Mats and Joseph,
> Good idea, I am going home now so I’ll look into that tomorrow.
> Alasdair
>
> > -----Original Message-----
> > From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
> > Sent: 11 October 2004 16:55
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] Losing Received Data?
> >
> >
> >
> >
> >
> >
> >
> > > PS. You can probably write a simple usermode program
> > > to run on the other side and generate this problem…
> > > just open the comm port and write a pretty good burst
> > > of data.
> >
> > This is a good idea. Instead of using the phone (which of
> > course is the ultimate target), use a PC with either standard
> > of custom software on it.
> > >
> > > You can probably also do it using hyperterms file
> > > transfer facility (ZModem/Xmodem I think it supports
> > > at least one of these.)
> > >
> > > Typing in hyperterm isn’t a good test since even with
> > > all the debugging, the computer is still probably faster
> > > than you are.
> >
> > I don’t know if Hyperterm supports it, but definitely some
> > other terminal programs (TeraTerm comes to mind, but I’m
> > unsure if this feature is
> > included) support logging and transmitting of text-files
> > (ASCII transfer mode). So buiild a text-file with a heap of
> > text that you can identify if it’s been transmitted correctly
> > at the other end, with varying lenghts and “no protocol”
> > (because using a protocol just confuses the issue) and send
> > some data across.
> >
> > If you write a little test-app, then one test method should
> > be to transmit a file and compare at the other end (so you
> > start the compare first, then start the transmit, and the
> > test-app shows which lines come across badly). That way, you
> > can test different patterns, sizes, etc, etc, and change the
> > test-setup without having to do too much programming.
> >
> > Writing custom test-tools is a big part of device drivers,
> > because you need to be able to do “directed testing”, e.g.
> > testing special cases without hitting some other stuff that
> > is currently not working, etc, etc.
> >
> >
> > –
> > Mats
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@t-mobile.co.uk To unsubscribe send a blank
> > email to xxxxx@lists.osr.com
> >
>

> NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential. If you have
> received this email in error please notify the sender immediately
> and delete this email from your system without copying or
> disseminating it or placing any reliance upon its contents. We
> cannot accept liability for any breaches of confidence arising
> through use of email. Any opinions expressed in this email
> (including attachments) are those of the author and do not
> necessarily reflect our opinions. We will not accept responsibility
> for any commitments made by our employees outside the scope of our
> business. We do not warrant the accuracy or completeness of such
information.
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@t-mobile.co.uk

> To unsubscribe send a blank email to xxxxx@lists.osr.com
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

> NOTICE AND DISCLAIMER:
> This email (including attachments) is confidential. If you have
> received this email in error please notify the sender immediately
> and delete this email from your system without copying or
> disseminating it or placing any reliance upon its contents. We
> cannot accept liability for any breaches of confidence arising
> through use of email. Any opinions expressed in this email
> (including attachments) are those of the author and do not
> necessarily reflect our opinions. We will not accept responsibility
> for any commitments made by our employees outside the scope of our
> business. We do not warrant the accuracy or completeness of such
information.
>
> ForwardSourceID:NT00005356

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email



This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

4

Just thought I’d add my few cents of (non-)wisdom to this…

The usual reason for NULL-EIP is that some function has overflown a local
array and written zero to the stack pointer.

There’s a fairly simple way to check this:
#define MAGIC 0x47111723
#define ENTRY_MACRO int entry = MAGIC
#define EXIT_MACRO ASSERT(entry == MAGIC)

func(…)
{
ENTRY_MACRO;
// some vairiables
…
… work done here
…
EXIT_MACRO;
return;
}

Obviously, ANY return statement in a function should have a matching
EXIT_MACRO

This isn’t completely foolproof, but it does catch the most common versions
of overwriting the stack with data, with very little extra code.

Of course, in the release build, you would want this to turn into “nothing”
with some suitable “#if” statement.

–
Mats
xxxxx@lists.osr.com wrote on 12/07/2004 12:16:27 PM:

I had a feeling that would be the answer to my problem.

Thanks anyway

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: 06 December 2004 19:12
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Overflow of somekind

Bugs with inter-thread synchronization are usually found by core
re-read
and not by debugging. They are very hard, and are better to be avoided
then
fixed.

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

----- Original Message -----
From: “Ceri Coburn”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, December 06, 2004 6:02 PM
> Subject: [ntdev] Overflow of somekind
>
>
>
> Hi,
>
> I have a crash that it giving me grief. EIP points to NULL so I suspect
> an overflow somewhere and I do not have a stack trace. Now the problem
> I have is that I have run Bounds Checker through it and Intel Thread
> Checker and none of them show any obvious problems related to the crash.
> It only happens on hyper-threaded and multi-processor machines which
> also give me a clue on some kind of synchronisation problem (but Intel
> Thread Checker didn’t find any). Anyone got any idea on how best to
> approach this bug?
>
> Thanks
> Ceri
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Mats PETERSSON
> Sent: 12 October 2004 09:36
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Losing Received Data?
>
>
>
>
>
>
> You could always use VTune (or some other performance profiling tool) to
> figure out what takes time in your driver (or someone elses driver).
>
> Debug output that doesn’t actually print anything (if you use levels for
> instance) will still take a fair amount of time, simply because of
> argument
> passing and calling the debut output function.
>
> But to achieve something like 60% CPU performance on a reasonably modern
> processor, you need to actually do quite a lot. Why not break into the
> system a few times and see where it’s at. (Press CTRL-Break and check
> the
> stack to see what’s going on). You should have a hit in whatever it is
> that
> takes a lot of time every other time. This is called “poor mans
> profiling”,
> and it actually works much better than you’d think.
>
> –
> Mats
>
> xxxxx@lists.osr.com wrote on 10/12/2004 08:55:25 AM:
>
> > Hi again,
> >
> > I noticed that when the driver was running under the debugger the
> > system load was very high, the red part of the graph indicating
> > kernel load was hovering around 60% when the driver was loaded and
> > with no serial comms taking place, I have no idea why. So I tried
> > the same (debug) version of the driver in the non-debug version of
> > W2K to remove any issues caused by the debugger and it’s serial
> > comms, system load was the same but the dial-up connection
> > succeeded! so I think it is a performance issue rather than a logic
> issue.
> >
> > I don’t know why the load should be so high, there are no threads in
> > the driver and as far as I am aware it should just be sitting there
> > doing nothing, you probably know better.
> >
> > My next test will be to see what the load is with the free version
> > of the driver.
> >
> > Thanks for the suggestions regarding using a test app to thrash the
> > comms, I may still need to resort to that but for time being I think
> > I will need to track down this load problem.
> >
> > As usual, any suggestions greatly appreciated.
> >
> > Thanks
> >
> > Alasdair
> >
> >
> > -----Original Message-----
> > From: Alasdair Tompson (external)
> [mailto:xxxxx@t-mobile.co.uk]
> > Sent: 11 October 2004 16:58
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] Losing Received Data?
>
> > Thanks Mats and Joseph,
> > Good idea, I am going home now so I’ll look into that tomorrow.
> > Alasdair
> >
> > > -----Original Message-----
> > > From: Mats PETERSSON [mailto:xxxxx@3dlabs.com]
> > > Sent: 11 October 2004 16:55
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] Losing Received Data?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > PS. You can probably write a simple usermode program
> > > > to run on the other side and generate this problem…
> > > > just open the comm port and write a pretty good burst
> > > > of data.
> > >
> > > This is a good idea. Instead of using the phone (which of
> > > course is the ultimate target), use a PC with either standard
> > > of custom software on it.
> > > >
> > > > You can probably also do it using hyperterms file
> > > > transfer facility (ZModem/Xmodem I think it supports
> > > > at least one of these.)
> > > >
> > > > Typing in hyperterm isn’t a good test since even with
> > > > all the debugging, the computer is still probably faster
> > > > than you are.
> > >
> > > I don’t know if Hyperterm supports it, but definitely some
> > > other terminal programs (TeraTerm comes to mind, but I’m
> > > unsure if this feature is
> > > included) support logging and transmitting of text-files
> > > (ASCII transfer mode). So buiild a text-file with a heap of
> > > text that you can identify if it’s been transmitted correctly
> > > at the other end, with varying lenghts and “no protocol”
> > > (because using a protocol just confuses the issue) and send
> > > some data across.
> > >
> > > If you write a little test-app, then one test method should
> > > be to transmit a file and compare at the other end (so you
> > > start the compare first, then start the transmit, and the
> > > test-app shows which lines come across badly). That way, you
> > > can test different patterns, sizes, etc, etc, and change the
> > > test-setup without having to do too much programming.
> > >
> > > Writing custom test-tools is a big part of device drivers,
> > > because you need to be able to do “directed testing”, e.g.
> > > testing special cases without hitting some other stuff that
> > > is currently not working, etc, etc.
> > >
> > >
> > > –
> > > Mats
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > > xxxxx@t-mobile.co.uk To unsubscribe send a blank
> > > email to xxxxx@lists.osr.com
> > >
> >
>
> > NOTICE AND DISCLAIMER:
> > This email (including attachments) is confidential. If you have
> > received this email in error please notify the sender immediately
> > and delete this email from your system without copying or
> > disseminating it or placing any reliance upon its contents. We
> > cannot accept liability for any breaches of confidence arising
> > through use of email. Any opinions expressed in this email
> > (including attachments) are those of the author and do not
> > necessarily reflect our opinions. We will not accept responsibility
> > for any commitments made by our employees outside the scope of our
> > business. We do not warrant the accuracy or completeness of such
> information.
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@t-mobile.co.uk
>
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > —
> > Questions? First check the Kernel Driver FAQ at http://www.
> > osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@3dlabs.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
>
> > NOTICE AND DISCLAIMER:
> > This email (including attachments) is confidential. If you have
> > received this email in error please notify the sender immediately
> > and delete this email from your system without copying or
> > disseminating it or placing any reliance upon its contents. We
> > cannot accept liability for any breaches of confidence arising
> > through use of email. Any opinions expressed in this email
> > (including attachments) are those of the author and do not
> > necessarily reflect our opinions. We will not accept responsibility
> > for any commitments made by our employees outside the scope of our
> > business. We do not warrant the accuracy or completeness of such
> information.
> >
> > ForwardSourceID:NT00005356
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
>
>
>
>
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
>
>
>
>
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.
> osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com

> ForwardSourceID:NT0000907E

5

> There’s a fairly simple way to check this:

#define MAGIC 0x47111723
#define ENTRY_MACRO int entry = MAGIC
#define EXIT_MACRO ASSERT(entry == MAGIC)

func(…)
{
ENTRY_MACRO;
// some vairiables
…
… work done here
…
EXIT_MACRO;
return;
}

“Security cookies” in recent MS compilers do this automatically. BTW, XPSP2
kernel is compiled with security cookies on.

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

6

I am pretty positive that it’s not a stack based overflow. My instincts
point me to a DeviceIoControl call that I’m using to read sectors off a
CD. Except that I can’t be fully positive about this because if I start
logging buffer sizes etc… it doesn’t crash (I’m assuming the timing
changes when logging). I think it’s a heap corruption. Well time to
sieve through pages of code.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: 07 December 2004 13:14
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Overflow of somekind

There’s a fairly simple way to check this:
#define MAGIC 0x47111723
#define ENTRY_MACRO int entry = MAGIC
#define EXIT_MACRO ASSERT(entry == MAGIC)

func(…)
{
ENTRY_MACRO;
// some vairiables
…
… work done here
…
EXIT_MACRO;
return;
}

“Security cookies” in recent MS compilers do this automatically. BTW,
XPSP2
kernel is compiled with security cookies on.

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

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

7

Use some overflow detection tools, you can capture at least
what’s in the stack or heap once it happens, it helps to analysis
the issue. Another thing you can try is, test your codes on a machine
which have build-in hardware overflow protection (like XEON), if you
are lucky to get the exception dump (I’m not sure it will report to OS or
not),
you can get the dirty codes then.
Just my two cents.

“Ceri Coburn” wrote in message
news:xxxxx@ntdev…
I am pretty positive that it’s not a stack based overflow. My instincts
point me to a DeviceIoControl call that I’m using to read sectors off a
CD. Except that I can’t be fully positive about this because if I start
logging buffer sizes etc… it doesn’t crash (I’m assuming the timing
changes when logging). I think it’s a heap corruption. Well time to
sieve through pages of code.

8

Hi,

Hmm, interesting. I have a dual XEON processor machine here. What
would be the best approach for this? Would WinDbg be able to get the
information I need or will I need specialist software for this?

Thanks

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: 07 December 2004 17:41
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Overflow of somekind

Use some overflow detection tools, you can capture at least
what’s in the stack or heap once it happens, it helps to analysis
the issue. Another thing you can try is, test your codes on a machine
which have build-in hardware overflow protection (like XEON), if you
are lucky to get the exception dump (I’m not sure it will report to OS
or
not),
you can get the dirty codes then.
Just my two cents.

“Ceri Coburn” wrote in message
news:xxxxx@ntdev…
I am pretty positive that it’s not a stack based overflow. My instincts
point me to a DeviceIoControl call that I’m using to read sectors off a
CD. Except that I can’t be fully positive about this because if I start
logging buffer sizes etc… it doesn’t crash (I’m assuming the timing
changes when logging). I think it’s a heap corruption. Well time to
sieve through pages of code.

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email



This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

9

Okay, in your case, if it’s really a heap or stack overflow,
on that 64bit machine, you can turn on the DEP protection
in boot.ini (exp: /NoExecute=OptOut, you may also need
enable PAE), I have played this on an AMD Athlon machine
running 32bit Windows XP SP2, it will catch the overflow
in applications right away, then you can have a chance to
attach a debugger on this application to see the overflow codes.
Hope it helps.

“Ceri Coburn” wrote in message
news:xxxxx@ntdev…
Hi,

Hmm, interesting. I have a dual XEON processor machine here. What
would be the best approach for this? Would WinDbg be able to get the
information I need or will I need specialist software for this?

Thanks

10

That is helpful, thanks a lot.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of AFei
Sent: 08 December 2004 18:19
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Overflow of somekind

Okay, in your case, if it’s really a heap or stack overflow,
on that 64bit machine, you can turn on the DEP protection
in boot.ini (exp: /NoExecute=OptOut, you may also need
enable PAE), I have played this on an AMD Athlon machine
running 32bit Windows XP SP2, it will catch the overflow
in applications right away, then you can have a chance to
attach a debugger on this application to see the overflow codes.
Hope it helps.

“Ceri Coburn” wrote in message
news:xxxxx@ntdev…
Hi,

Hmm, interesting. I have a dual XEON processor machine here. What
would be the best approach for this? Would WinDbg be able to get the
information I need or will I need specialist software for this?

Thanks

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email



This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

11

> I am pretty positive that it’s not a stack based overflow. My instincts

point me to a DeviceIoControl call that I’m using to read sectors off a
CD. Except that I can’t be fully positive about this because if I start
logging buffer sizes etc… it doesn’t crash (I’m assuming the timing
changes when logging). I think it’s a heap corruption. Well time to
sieve through pages of code.

I assume your suspect buffer is on the stack that gets zapped.
Stick a dummy variable of 32 bytes or so after the buffer, initialize it to
a known pattern before each IO, and see if it gets zapped too. That could
give you a fair idea what is happening.

Loren

12

Hi,

That’s the main problem, I had checked, checked and double checked. It
was not a stack overflow.

It turned out to be some filter driver on the CD-ROM class that was
causing it. After I had taken it away, the application worked like a
charm.

Thanks Guys

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: 09 December 2004 06:13
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Overflow of somekind

I am pretty positive that it’s not a stack based overflow. My
instincts
point me to a DeviceIoControl call that I’m using to read sectors off
a
CD. Except that I can’t be fully positive about this because if I
start
logging buffer sizes etc… it doesn’t crash (I’m assuming the timing
changes when logging). I think it’s a heap corruption. Well time to
sieve through pages of code.

I assume your suspect buffer is on the stack that gets zapped.
Stick a dummy variable of 32 bytes or so after the buffer, initialize it
to
a known pattern before each IO, and see if it gets zapped too. That
could
give you a fair idea what is happening.

Loren

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email

13

Be careful about blaming a filter driver. The cause of the problem
could actually be in your software, simply that the symptoms become
apparent when the filter driver is in place. In the most nightmarish
scenario, by removing the suspect filter driver you’ve simply altered
the specific timing conditions under which the problem appears, to the
point where it occurs so infrequently on your test system
configuration(s) that you incorrectly conclude the problem is gone.

Chuck

----- Original Message -----
From: “Ceri Coburn”
To: “Windows System Software Devs Interest List”
Sent: Thursday, December 09, 2004 4:08 PM
Subject: RE: [ntdev] Overflow of somekind

> Hi,
>
> That’s the main problem, I had checked, checked and double checked.
> It
> was not a stack overflow.
>
> It turned out to be some filter driver on the CD-ROM class that was
> causing it. After I had taken it away, the application worked like a
> charm.
>
> Thanks Guys
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
> Sent: 09 December 2004 06:13
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Overflow of somekind
>
>> I am pretty positive that it’s not a stack based overflow. My
> instincts
>> point me to a DeviceIoControl call that I’m using to read sectors off
> a
>> CD. Except that I can’t be fully positive about this because if I
> start
>> logging buffer sizes etc… it doesn’t crash (I’m assuming the timing
>> changes when logging). I think it’s a heap corruption. Well time to
>> sieve through pages of code.
>
> I assume your suspect buffer is on the stack that gets zapped.
> Stick a dummy variable of 32 bytes or so after the buffer, initialize
> it
> to
> a known pattern before each IO, and see if it gets zapped too. That
> could
> give you a fair idea what is happening.
>
> Loren

14

Hi,

I tried a newer version of the software which installs this filter
driver and it all seems fine now. But your point is noted.

Ceri

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chuck Batson
Sent: 09 December 2004 10:07
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Overflow of somekind

Be careful about blaming a filter driver. The cause of the problem
could actually be in your software, simply that the symptoms become
apparent when the filter driver is in place. In the most nightmarish
scenario, by removing the suspect filter driver you’ve simply altered
the specific timing conditions under which the problem appears, to the
point where it occurs so infrequently on your test system
configuration(s) that you incorrectly conclude the problem is gone.

Chuck

----- Original Message -----
From: “Ceri Coburn”
To: “Windows System Software Devs Interest List”
Sent: Thursday, December 09, 2004 4:08 PM
Subject: RE: [ntdev] Overflow of somekind

> Hi,
>
> That’s the main problem, I had checked, checked and double checked.
> It
> was not a stack overflow.
>
> It turned out to be some filter driver on the CD-ROM class that was
> causing it. After I had taken it away, the application worked like a
> charm.
>
> Thanks Guys
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
> Sent: 09 December 2004 06:13
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Overflow of somekind
>
>> I am pretty positive that it’s not a stack based overflow. My
> instincts
>> point me to a DeviceIoControl call that I’m using to read sectors off
> a
>> CD. Except that I can’t be fully positive about this because if I
> start
>> logging buffer sizes etc… it doesn’t crash (I’m assuming the timing
>> changes when logging). I think it’s a heap corruption. Well time to
>> sieve through pages of code.
>
> I assume your suspect buffer is on the stack that gets zapped.
> Stick a dummy variable of 32 bytes or so after the buffer, initialize
> it
> to
> a known pattern before each IO, and see if it gets zapped too. That
> could
> give you a fair idea what is happening.
>
> Loren

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

You are currently subscribed to ntdev as: xxxxx@first4internet.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email



This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email