I saw this little new item today in the hardware newsletter - did I miss
this somewhere else or is this really the first mention?
Anyways, anybody from msft listening - please no! I download
windbg routinely on client machines I need to debug. I really don’t want
to have to install or extract windbg from the wdk to do this. Having it
part of the WDK is fine, but we really really need a standalone install
too.
t.
“Debugging Tools for Windows Available Only in WDK and Windows SDK
Starting with the current version (6.12.1.591), Debugging Tools for
Windows is available only as part of the Windows Driver Kit (WDK). This
version will also be made available in an upcoming release of the Windows
Software Development Kit (SDK).
To download the WDK and install Debugging Tools for Windows:
1. Download and install the WDK
(http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx).
2. Find the debugging tools link on the screen that appears and click to
install the debuggers to a location of your choice.
3. After the installation is complete, you can find the debugger shortcuts
by clicking Start, pointing to All Programs, and then pointing to
Debugging Tools for Windows.
Note: Windows Symbols Packages are not available in the WDK and are still
available on WHDC
(http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx).”
If true, this is a terrible, terrible, terrible idea.
I agree with everything Tracy said, and would that as it currently stands, in my opinion, the new wdk installer (KitSetup.exe) still doesn’t work correctly and can trash your windbg installation, or at least I’ve seen it do that in a few cases. I imagine that the windbg installer can be extracted and used separately, but that’s just going to make the problem worse.
More fundamentally, bundling anything else into an installer that has several known problems is just not a good idea, in my opinion, even if the package will still be available separately. On top of that, as it currently stands, the current (6.11.1.404) windbg installer doesn’t work in some cases where old versions of the 1394 transport drivers are present, so it’s really bundling an installer that has issues into another one that also has issues.
I don’t get that newsletter. Is there a link to this information? I just checked the windbg download page (http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx) and it doesn’t mention this little tidbit, nor does it say anything about a new version (6.12.1.591), so now I’m really wondering what the deal is.
mm
I’m signed up for something through connect called The “Micrsoft Hardware
Newsletter” - it is surprisingly informative and I would recommend
subscribing. This was the first and only mention I’ve seen - hopefully
something was missed in translation.
t.
On Wed, 20 Jan 2010, xxxxx@evitechnology.com wrote:
If true, this is a terrible, terrible, terrible idea.
I agree with everything Tracy said, and would that as it currently stands, in my opinion, the new wdk installer (KitSetup.exe) still doesn’t work correctly and can trash your windbg installation, or at least I’ve seen it do that in a few cases. I imagine that the windbg installer can be extracted and used separately, but that’s just going to make the problem worse.
More fundamentally, bundling anything else into an installer that has several known problems is just not a good idea, in my opinion, even if the package will still be available separately. On top of that, as it currently stands, the current (6.11.1.404) windbg installer doesn’t work in some cases where old versions of the 1394 transport drivers are present, so it’s really bundling an installer that has issues into another one that also has issues.
I don’t get that newsletter. Is there a link to this information? I just checked the windbg download page (http://www.microsoft.com/whdc/devtools/debugging/installx86.Mspx) and it doesn’t mention this little tidbit, nor does it say anything about a new version (6.12.1.591), so now I’m really wondering what the deal is.
mm
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) 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
As listed on the public debugging page, mailto:xxxxx
is the Windbg team feedback alias. You could try sending them some
business reasons why your Windows development efforts will be hampered
if Windbg is only in the SDK|WDK, not on the CSD or on the public web
site. I have no idea if they are paying attention to feedback anymore.</mailto:xxxxx>
Sadly, I suspect that sending business reasons will fall upon deaf ears. This seems to be another example in which the community’s needs are determined without consulting with the community - much like any large, bureaucratic organization does on the behalf of its constituency.
In all fairness, Microsoft builds the WDK and the kernel debugger as a gift to our community - they really do not gain anything from it (it’s not as if we pay for it.) Arguing that it is inconvenient to US has little merit - it is not going to make any difference for the business case for Microsoft (or more likely for the group that pays to produce the current debugger package.) In some ways, I’m surprised someone there hasn’t realized that this is little more than a cost with no corresponding income stream that could simply be eliminated and save someone’s P&L quite a lot of expense that generates no corresponding income.
Now maybe if we paid for these tools we’d have the right to expect our feedback to count for something, but as beggars at the table, we really need to keep in mind that we should be grateful for the crumbs that fall.
Tony
OSR
But the kernel debugger is built for INTERNAL use.
There is almost no additional cost to distributing it to the community. In fact, one could argue they gain benefit by increasing the knowledgeable pool of testers.
Peter
OSR