Persistent Older versions

I just had a problem that was frustrating beyond imagining. I had recently
created a new project based on an existing project. I created a new
directory structure, added a new files, resolved namespace and function
calls and finally installed and began testing. No matter what I tried WinDbg
would not find and sync the source files. Every time I started the driver to
step into the new code, the breakpoint landed somewhere in the middle of the
new functionality. I manually removed the old and new symbols and sys files
from my local symbols cache, rebuilt the drivers a multitude of times,
checked the date/time stamp on the symbols and sys files in the cache,
modified .kdfiles to reflect the new paths and file names but absolutely
NOTHING worked.

I don’t know why, but I finally looked at the names of the source files
WinDbg was using and sho’nuff good buddy all the source windows in WinDbg
reflected the old project source. No wonder nothing was in sync!!! Grrrr
… three hours spent on this when I don’t have 3 hours to waste, but then
Murphy always said when you don’t have time for it, the stupidest things are
going to happen.

Case in point: when you make massive changes to projects, or move to a new
project, close the source files that WinDbg has open. I think part of the
issue may have been the closeness of the file names in use: theDriverV2 vs
theDriverV3.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

Well, this was SUPPOSED to be in the WinDbg forum. Another note to self:
check To: box before sending. :frowning:

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, September 06, 2010 1:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Persistent Older versions

I just had a problem that was frustrating beyond imagining. I had recently
created a new project based on an existing project. I created a new
directory structure, added a new files, resolved namespace and function
calls and finally installed and began testing. No matter what I tried WinDbg
would not find and sync the source files. Every time I started the driver to
step into the new code, the breakpoint landed somewhere in the middle of the
new functionality. I manually removed the old and new symbols and sys files
from my local symbols cache, rebuilt the drivers a multitude of times,
checked the date/time stamp on the symbols and sys files in the cache,
modified .kdfiles to reflect the new paths and file names but absolutely
NOTHING worked.

I don’t know why, but I finally looked at the names of the source files
WinDbg was using and sho’nuff good buddy all the source windows in WinDbg
reflected the old project source. No wonder nothing was in sync!!! Grrrr
… three hours spent on this when I don’t have 3 hours to waste, but then
Murphy always said when you don’t have time for it, the stupidest things are
going to happen.

Case in point: when you make massive changes to projects, or move to a new
project, close the source files that WinDbg has open. I think part of the
issue may have been the closeness of the file names in use: theDriverV2 vs
theDriverV3.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net


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

In the past I saw this problem. So first thing I would make sure that the pdb file loaded is the correct version. Then from the menu open source file from source directory that has current source. But I guess you ran into some deeper problem!

-pro

On Sep 6, 2010, at 11:35 AM, Gary G. Little wrote:

Well, this was SUPPOSED to be in the WinDbg forum. Another note to self:
check To: box before sending. :frowning:

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, September 06, 2010 1:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Persistent Older versions

I just had a problem that was frustrating beyond imagining. I had recently
created a new project based on an existing project. I created a new
directory structure, added a new files, resolved namespace and function
calls and finally installed and began testing. No matter what I tried WinDbg
would not find and sync the source files. Every time I started the driver to
step into the new code, the breakpoint landed somewhere in the middle of the
new functionality. I manually removed the old and new symbols and sys files
from my local symbols cache, rebuilt the drivers a multitude of times,
checked the date/time stamp on the symbols and sys files in the cache,
modified .kdfiles to reflect the new paths and file names but absolutely
NOTHING worked.

I don’t know why, but I finally looked at the names of the source files
WinDbg was using and sho’nuff good buddy all the source windows in WinDbg
reflected the old project source. No wonder nothing was in sync!!! Grrrr
… three hours spent on this when I don’t have 3 hours to waste, but then
Murphy always said when you don’t have time for it, the stupidest things are
going to happen.

Case in point: when you make massive changes to projects, or move to a new
project, close the source files that WinDbg has open. I think part of the
issue may have been the closeness of the file names in use: theDriverV2 vs
theDriverV3.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net


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


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

I’ve seen this before, far too often. Windbg appears to not disambiguate
source names based on the full path. So if it comes up with an existing
workspace that has foo.c in it, any attempt to resolve a new foo.c will
revert to the older file in the older project. Seems like it would be easy
to get right, but windbg doesn’t handle it right.

Note: this is the same program that pops up message boxes UNDER the command
window, so perhaps it is too much to expect that it will do something this
complex correctly.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Monday, September 06, 2010 8:12 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Persistent Older versions

In the past I saw this problem. So first thing I would make sure that the
pdb file loaded is the correct version. Then from the menu open source file
from source directory that has current source. But I guess you ran into some
deeper problem!

-pro

On Sep 6, 2010, at 11:35 AM, Gary G. Little wrote:

Well, this was SUPPOSED to be in the WinDbg forum. Another note to self:
check To: box before sending. :frowning:

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, September 06, 2010 1:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Persistent Older versions

I just had a problem that was frustrating beyond imagining. I had recently
created a new project based on an existing project. I created a new
directory structure, added a new files, resolved namespace and function
calls and finally installed and began testing. No matter what I tried
WinDbg
would not find and sync the source files. Every time I started the driver
to
step into the new code, the breakpoint landed somewhere in the middle of
the
new functionality. I manually removed the old and new symbols and sys
files
from my local symbols cache, rebuilt the drivers a multitude of times,
checked the date/time stamp on the symbols and sys files in the cache,
modified .kdfiles to reflect the new paths and file names but absolutely
NOTHING worked.

I don’t know why, but I finally looked at the names of the source files
WinDbg was using and sho’nuff good buddy all the source windows in WinDbg
reflected the old project source. No wonder nothing was in sync!!! Grrrr
… three hours spent on this when I don’t have 3 hours to waste, but then
Murphy always said when you don’t have time for it, the stupidest things
are
going to happen.

Case in point: when you make massive changes to projects, or move to a new
project, close the source files that WinDbg has open. I think part of the
issue may have been the closeness of the file names in use: theDriverV2 vs
theDriverV3.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net


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


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


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


This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Have you (op) set ‘.srcpath?’

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 10:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Persistent Older versions

I’ve seen this before, far too often. Windbg appears to not disambiguate
source names based on the full path. So if it comes up with an existing
workspace that has foo.c in it, any attempt to resolve a new foo.c will
revert to the older file in the older project. Seems like it would be easy
to get right, but windbg doesn’t handle it right.

Note: this is the same program that pops up message boxes UNDER the command
window, so perhaps it is too much to expect that it will do something this
complex correctly.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Monday, September 06, 2010 8:12 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Persistent Older versions

In the past I saw this problem. So first thing I would make sure that the
pdb file loaded is the correct version. Then from the menu open source file
from source directory that has current source. But I guess you ran into some
deeper problem!

-pro

On Sep 6, 2010, at 11:35 AM, Gary G. Little wrote:

Well, this was SUPPOSED to be in the WinDbg forum. Another note to self:
check To: box before sending. :frowning:

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, September 06, 2010 1:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Persistent Older versions

I just had a problem that was frustrating beyond imagining. I had
recently created a new project based on an existing project. I created
a new directory structure, added a new files, resolved namespace and
function calls and finally installed and began testing. No matter what
I tried
WinDbg
would not find and sync the source files. Every time I started the
driver
to
step into the new code, the breakpoint landed somewhere in the middle
of
the
new functionality. I manually removed the old and new symbols and sys
files
from my local symbols cache, rebuilt the drivers a multitude of times,
checked the date/time stamp on the symbols and sys files in the cache,
modified .kdfiles to reflect the new paths and file names but
absolutely NOTHING worked.

I don’t know why, but I finally looked at the names of the source
files WinDbg was using and sho’nuff good buddy all the source windows
in WinDbg reflected the old project source. No wonder nothing was in
sync!!! Grrrr … three hours spent on this when I don’t have 3 hours
to waste, but then Murphy always said when you don’t have time for it,
the stupidest things
are
going to happen.

Case in point: when you make massive changes to projects, or move to a
new project, close the source files that WinDbg has open. I think part
of the issue may have been the closeness of the file names in use:
theDriverV2 vs theDriverV3.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net


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


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


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


This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


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

Make sure your File->Source directories path is empty. Because Winbug doesn’t allow to clean it, I set ‘.’ to it.

WIth one old version I had a problem when the !analyze command was showing source fragment from stale version, no matter how I tried.

Good point mm, but it is set, though I do note it has a paths to both the
old and new source directories.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
Sent: Wednesday, September 08, 2010 9:29 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Persistent Older versions

Have you (op) set ‘.srcpath?’

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
Sent: Wednesday, September 08, 2010 10:26 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Persistent Older versions

I’ve seen this before, far too often. Windbg appears to not disambiguate
source names based on the full path. So if it comes up with an existing
workspace that has foo.c in it, any attempt to resolve a new foo.c will
revert to the older file in the older project. Seems like it would be easy
to get right, but windbg doesn’t handle it right.

Note: this is the same program that pops up message boxes UNDER the command
window, so perhaps it is too much to expect that it will do something this
complex correctly.
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
Sent: Monday, September 06, 2010 8:12 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Persistent Older versions

In the past I saw this problem. So first thing I would make sure that the
pdb file loaded is the correct version. Then from the menu open source file
from source directory that has current source. But I guess you ran into some
deeper problem!

-pro

On Sep 6, 2010, at 11:35 AM, Gary G. Little wrote:

Well, this was SUPPOSED to be in the WinDbg forum. Another note to self:
check To: box before sending. :frowning:

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Monday, September 06, 2010 1:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Persistent Older versions

I just had a problem that was frustrating beyond imagining. I had
recently created a new project based on an existing project. I created
a new directory structure, added a new files, resolved namespace and
function calls and finally installed and began testing. No matter what
I tried
WinDbg
would not find and sync the source files. Every time I started the
driver
to
step into the new code, the breakpoint landed somewhere in the middle
of
the
new functionality. I manually removed the old and new symbols and sys
files
from my local symbols cache, rebuilt the drivers a multitude of times,
checked the date/time stamp on the symbols and sys files in the cache,
modified .kdfiles to reflect the new paths and file names but
absolutely NOTHING worked.

I don’t know why, but I finally looked at the names of the source
files WinDbg was using and sho’nuff good buddy all the source windows
in WinDbg reflected the old project source. No wonder nothing was in
sync!!! Grrrr … three hours spent on this when I don’t have 3 hours
to waste, but then Murphy always said when you don’t have time for it,
the stupidest things
are
going to happen.

Case in point: when you make massive changes to projects, or move to a
new project, close the source files that WinDbg has open. I think part
of the issue may have been the closeness of the file names in use:
theDriverV2 vs theDriverV3.

Gary G. Little
H (952) 223-1349
C (952) 454-4629
xxxxx@comcast.net


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


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


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


This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


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


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

Having your source path set properly is key in these situations. Once you
start moving your source around you have to be explicit about where WinDBG
should find it (and the order in the search path indicates precedence).

-scott


Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

“Gary G. Little” wrote in message
news:xxxxx@ntdev…
> Good point mm, but it is set, though I do note it has a paths to both the
> old and new source directories.
>
> Gary G. Little
> H (952) 223-1349
> C (952) 454-4629
> xxxxx@comcast.net
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of M. M. O’Brien
> Sent: Wednesday, September 08, 2010 9:29 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Persistent Older versions
>
> Have you (op) set ‘.srcpath?’
>
>
> Good luck,
>
> mm
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph M. Newcomer
> Sent: Wednesday, September 08, 2010 10:26 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Persistent Older versions
>
> I’ve seen this before, far too often. Windbg appears to not disambiguate
> source names based on the full path. So if it comes up with an existing
> workspace that has foo.c in it, any attempt to resolve a new foo.c will
> revert to the older file in the older project. Seems like it would be
> easy
> to get right, but windbg doesn’t handle it right.
>
> Note: this is the same program that pops up message boxes UNDER the
> command
> window, so perhaps it is too much to expect that it will do something this
> complex correctly.
> joe
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
> Sent: Monday, September 06, 2010 8:12 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Persistent Older versions
>
> In the past I saw this problem. So first thing I would make sure that the
> pdb file loaded is the correct version. Then from the menu open source
> file
> from source directory that has current source. But I guess you ran into
> some
> deeper problem!
>
> -pro
>
> On Sep 6, 2010, at 11:35 AM, Gary G. Little wrote:
>
>> Well, this was SUPPOSED to be in the WinDbg forum. Another note to self:
>> check To: box before sending. :frowning:
>>
>> Gary G. Little
>> H (952) 223-1349
>> C (952) 454-4629
>> xxxxx@comcast.net
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com
>> [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
>> Sent: Monday, September 06, 2010 1:27 PM
>> To: Windows System Software Devs Interest List
>> Subject: [ntdev] Persistent Older versions
>>
>> I just had a problem that was frustrating beyond imagining. I had
>> recently created a new project based on an existing project. I created
>> a new directory structure, added a new files, resolved namespace and
>> function calls and finally installed and began testing. No matter what
>> I tried
> WinDbg
>> would not find and sync the source files. Every time I started the
>> driver
> to
>> step into the new code, the breakpoint landed somewhere in the middle
>> of
> the
>> new functionality. I manually removed the old and new symbols and sys
> files
>> from my local symbols cache, rebuilt the drivers a multitude of times,
>> checked the date/time stamp on the symbols and sys files in the cache,
>> modified .kdfiles to reflect the new paths and file names but
>> absolutely NOTHING worked.
>>
>> I don’t know why, but I finally looked at the names of the source
>> files WinDbg was using and sho’nuff good buddy all the source windows
>> in WinDbg reflected the old project source. No wonder nothing was in
>> sync!!! Grrrr … three hours spent on this when I don’t have 3 hours
>> to waste, but then Murphy always said when you don’t have time for it,
>> the stupidest things
> are
>> going to happen.
>>
>> Case in point: when you make massive changes to projects, or move to a
>> new project, close the source files that WinDbg has open. I think part
>> of the issue may have been the closeness of the file names in use:
>> theDriverV2 vs theDriverV3.
>>
>> Gary G. Little
>> H (952) 223-1349
>> C (952) 454-4629
>> xxxxx@comcast.net
>>
>>
>>
>>
>> —
>> 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
>>
>>
>> —
>> 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
>
>
> —
> 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
>
> –
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>
>
> —
> 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
>
>
> —
> 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
>
>

> I’ve seen this before, far too often. Windbg appears to not disambiguate

source names based on the full path.

Exactly so, I second this.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com