WinDbg quick tip (II)

NTDEV
1

A few hours back I posted a message to the list asking for a quick tip
on some WinDbg messages referring to “memory leaks” on a typical
kernel debug session.

On Monday, March 05, 2001 4:04 PM “Barila, Phil” wrote:

Miguel,

Welcome to the world of Windows device driver development. What you
are
seeing are (some of) the bugs in the Checked build of Windows 2000. As
surprising as it may be to you, there are some bugs that got left in
when
Windows 2000 was frozen and shipped. You won’t see those messages if
you
connect your debugger to the Free build, because all the DbgPrints end
up
being compiled out. No way to tell if the bugs are still there. :slight_smile:

:))) (no comments…)

I’m not absolutely sure, but I don’t think mobsync has anything to do
with
the debugger.

Phil

From what I see, mobsync.exe (the Microsoft Synchronization Manager) is
probably used somewhere in the system and I suspect that it might be
responsible for some kind of synchronization problems I had in the past
while
using older WinDbg (pre?-)releases - namely, I had to give a .resync
command
(which worked once in a while, but not always…) to achieve
synchronization
between the host and the target machines. Actually, the WinDbg “release”
came
up with the DDK itself and while everyone else was talking about the new
“version 2”
of WinDbg I kept getting “version 5.00.2195.xxxx” (the O.S.!?) from the
About
box on WinDbg… :frowning:

Finally, I realized the WinDbg I was using was some kind of pre-release
that came
up with the DDK, so I simply quit using it: instead, I’ve downloaded
WinDbg v2.0.0023
from the web, installed it (funny enough, NOT! on the DDK directory, but
under
Program Files\Debugging Tools for Windows…) and this is the one I’m
using now
(can someone tell me why Microsoft does such a mess when it comes to
simplifying
developer’s work?.. oh well…)

Back to the point. What it seems to me is happening now is:

  1. WinDbg v2.0.0023 is much reliable now, a lot of configuration
    efforts have been
    done, which indeed simplified its usage; whatever the “synchronization
    bug” was is now fixed,
    so forget about it;

  2. I wouldn’t be surprised if the mobsync.exe file I have installed
    (that came with Win2K and
    perhaps could have been updated when I upgraded Win2K to SP 1) is a
    “buggy” or updated
    version that has some kind of conflict with the O.S. itself (the
    Properties tab for this file states
    File Version is 5.0.2139.1… the O.S. is 5.0.2195… could the build
    numbers mean something
    here? I dunno… I rest my case…);

  3. Finally, the “memory leakings” could be hapenning for a million
    reasons. Yet, there is a
    chance there’s an undetected bug lying beneath CDebugMalloc… if
    someone out there has
    the knowledge to investigate this (I’m not yet, sorry) and time
    (oooh…), maybe this is a chance
    for you to win the Windows DDK Bug Bash… :)))

Anyway, thank you Phil for your kind answer. I think I can live with it
for now… :slight_smile:

Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com

«Humour and love are God’s answers
to Human weaknesses»

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

Miguel,

Try running mobsync.exe on your development system, if you have Win2K on it.
Otherwise, boot your debug target and run it there. It has absolutely
nothing to do with the sync problems you had using the old versions of
WinDBG. Of that I am absolutely sure, and if you run it, you’ll see why I
am so sure. It’s a webpage download robot. It has nothing to do with the
debugger, except that it has bugs. The fact that it’s name has ‘sync’ in
it, and you had synchronization issues is incidental.

CDebugMalloc is a function in the debug version of the MFC library. Since
the entire checked build of the OS is a “debug” version, it’s not surprising
that it gets called. What is slightly surprising is that the OS, and SP1,
shipped while still reporting memory leaks. Note to marketing: It’s
*really* a good idea to fix bugs *that* obvious, before you ship the
product.

Like I mentioned before, none of these debug messages appears in the Free
build of the OS, but that isn’t evidence for or against the presence of the
bugs that caused them.

Phil

-----Original Message-----
From: Miguel Monteiro [mailto:xxxxx@criticalsoftware.com]
Sent: Monday, March 05, 2001 9:55 AM
To: NT Developers Interest List
Subject: [ntdev] WinDbg quick tip (II)

A few hours back I posted a message to the list asking for a quick tip
on some WinDbg messages referring to “memory leaks” on a typical
kernel debug session.

On Monday, March 05, 2001 4:04 PM “Barila, Phil” wrote:

[snip]

From what I see, mobsync.exe (the Microsoft Synchronization Manager) is
probably used somewhere in the system and I suspect that it might be
responsible for some kind of synchronization problems I had in the past
while
using older WinDbg (pre?-)releases - namely, I had to give a .resync
command
(which worked once in a while, but not always…) to achieve
synchronization
between the host and the target machines. Actually, the WinDbg “release”
came
up with the DDK itself and while everyone else was talking about the new
“version 2”
of WinDbg I kept getting “version 5.00.2195.xxxx” (the O.S.!?) from the
About
box on WinDbg… :frowning:

Finally, I realized the WinDbg I was using was some kind of pre-release
that came
up with the DDK, so I simply quit using it: instead, I’ve downloaded
WinDbg v2.0.0023
from the web, installed it (funny enough, NOT! on the DDK directory, but
under
Program Files\Debugging Tools for Windows…) and this is the one I’m
using now
(can someone tell me why Microsoft does such a mess when it comes to
simplifying
developer’s work?.. oh well…)

Back to the point. What it seems to me is happening now is:

  1. WinDbg v2.0.0023 is much reliable now, a lot of configuration
    efforts have been
    done, which indeed simplified its usage; whatever the “synchronization
    bug” was is now fixed,
    so forget about it;

  2. I wouldn’t be surprised if the mobsync.exe file I have installed
    (that came with Win2K and
    perhaps could have been updated when I upgraded Win2K to SP 1) is a
    “buggy” or updated
    version that has some kind of conflict with the O.S. itself (the
    Properties tab for this file states
    File Version is 5.0.2139.1… the O.S. is 5.0.2195… could the build
    numbers mean something
    here? I dunno… I rest my case…);

  3. Finally, the “memory leakings” could be hapenning for a million
    reasons. Yet, there is a
    chance there’s an undetected bug lying beneath CDebugMalloc… if
    someone out there has
    the knowledge to investigate this (I’m not yet, sorry) and time
    (oooh…), maybe this is a chance
    for you to win the Windows DDK Bug Bash… :)))

Anyway, thank you Phil for your kind answer. I think I can live with it
for now… :slight_smile:

You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com