none
.mdmp files not being created

    Question

  • Hello, Under what conditions is the .mdmp file created or not?  I have written an app that (deliberately) dereferences a NULL pointer, but the generated error report does not have the "Files that help describe the problem" section when listing the report from the Control Panel "Problem Reports and Solutions".  Viewing other reports that had been put there, some of them have the files and some don't.

     

    DrWtsn32 on WinXP does create a minidump when my program crashes, and I would like the same behavior to occur on Vista.  How can I configure WER to create a minidump in this instance?

     

    Thanks,

    David (MVP, Visual C++)

     

    • Moved by Max Wang_Chinasoft Tuesday, April 26, 2011 5:33 PM forum consolidation (From:Windows Error Reporting for ISVs)
    Tuesday, June 26, 2007 10:40 AM

Answers

  • David,

     

    on Vista, minidumps are transmitted only upon explicit demand from the server, at least that is how I understand it. Jason Hardester's post at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1426737&SiteID=1 explains some of the rationale behind the server's decisions.

     

    You can force the system to always generate minidumps by enabling queuing mode: Set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ForceQueue (DWORD) to 1. Crash report data are stored in c:\Users\someusername\AppData\Local\temp and C:\ProgramData\Microsoft\Windows\WER\ReportQueue.

     

    Hope this helps,

     

      Claus

     

    http://www.clausbrod.de/Blog

     

     

    Tuesday, June 26, 2007 12:57 PM
  • I used ForceQueue for debugging purposes only, and the fact that the dialogs didn't appear was acceptable in that scenario.

     

    If you register and map your app with the Winqual servers, then the servers will at least occasionally request minidump information from your app, and then you'll be able to download the minidumps from Winqual.

     

    Another option is to shut off the Internet connection when the crash occurs. The dialogs will then be displayed, but when WER finds out it cannot send stuff to the servers, it will archive the crash data (including minidumps) so that they can be re-sent at some later point in time.

     

    A variation of this idea is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\CorporateWERServer to the name of some machine in your network. When a crash occurs, WER will assume that a "Corporate Error Reporting" server is running on that box, and will try to talk to port 1273. If there's no answer, then WER will probably create the minidump and keep it around for later.

     

    Of course, you could also set up a real Corporate Error Reporting server which always requests the minidump information from the client. I haven't tried this myself yet, though.

     

    Claus

     

    http://www.clausbrod.de/Blog

     

     

    Tuesday, June 26, 2007 8:41 PM
  • Just a wild idea which I'm sure Jason may not like so much (and I understand why) :

    • Call SetUnhandledExceptionFilter to register your own top-level exception filter code.
    • In that exception filter, call MiniDumpWriteDump to create a minidump file of your own describing the crash.
    • Return from the filter with EXCEPTION_CONTINUE_SEARCH.

    Check out http://www.clausbrod.de/Blog/DefinePrivatePublic20070627 for some demo code! 

     

    Cheers,

     

      Claus

     

     

     

     

    Wednesday, June 27, 2007 7:47 PM
  • The registry value name is "ForceQueue", not "ReportQueue". See http://msdn2.microsoft.com/en-us/library/aa363489.aspx for Microsoft's documentation on WER-related registry settings. (Those registry keys, by the way, are completely independent from the MiniDumpWriteDump() demo code I posted.)

     

    Hope this helps,

     

    Claus

     

    Thursday, June 28, 2007 4:48 AM
  • Hi David,

     

    What Operating Systems are you creating minidump tutorials for?  The behavior is different in Windows Vista than it is in older operating systems.

     

    Let me address various ways to get minidumps on the local machines for 'sneaker-net' and then direct you to what we had envisioned.

     

    Sneaker-net

    If you map your files on winqual, we will put the server into collection mode for your file's crashes.  This is interesting to you for the sneaker-net approach since minidumps are only stored locally in Windows Vista if the servers were collecting data at the time of the report.  (...also, I believe the minidump will be available if the computer is offline)

    Sneaker-net approach for older operating systems is easy... set up CER policies to report crash information to a local folder or shared folder, and have the 'Cabs' folder sent to you via whatever transport = sneaker-net.  You don't need to change your code, but you do need to be aware of expected client side behavior to be successful in the sneaker-net approach.  For example, CER is not supported in Windows Vista.  Instead, AEM is the method to use (the protocol is different).  AEM requires Operations Manager 2007, so there is overhead for an IT shop if they are not already leveraging this technology whereas CER was overly simple.  On Windows Vista, there is another solution (target's end-users) called Problem Reports and Solutions ...or wercon.exe.  If the back-end services were collecting data for the crash, the same data is available through wercon.exe.

     

    What Microsoft had envisioned

    For Developers - We had envisioned developers and ISVs to use Winqual to access crash information by mapping their products/files.  In this way, it did not matter where the report came from; Winqual would prioritize failures based on volume and growth of the reports over 90 days and enable developers and ISVs to create responses that would be displayed tot eh users if they encountered the crash again with information that could prevent the crash (update available, workaround, and so on).  Error Reporting for Applications happens by default without any needed application code unless the application is handling their own exceptions (...and as Claus mentioned, I don't encourage anyone to implement their own exception handler). 

     

    For IT-PROs - We had also envisioned the need for IT-Professionals (System/Network  administrators of companies) to manage what should be allowed to leave the corporate wire in regards to error reporting.  To achieve this management in the past, we offered Corporate Error Reporting.  This was a set of client policies and a tool that redirected error reports from within the IT shop to a common location where the Admin could use the tool to configure common reporting behavior and broker the data to Microsoft for the types of data the Admin allowed. (See CER).  This solution was not scalable for large IT-PRO shops as the tool used local memory to load the crash data in the common folder and apply the reporting rules.  The larger the share size and # of unique reports the longer it would take to load and report.  For Windows Vista,   it was decided to change the reporting protocol to use http/https and interact with Operations Manager 2007 using AEM (Agentless Event Management).

     

    For End Users - Finally, we had envisioned that it would be useful for an end-user top see (historically) what Error Reporting events happened on their computer.  To enable this, we created wercon.exe.  Through this tool, users can not only see what happened in the past, but they can check for solutions (responses) without having to wait for the crash to happen again.  The tool does keep crash data around in a queue so to prevent unneeded utilization of disk space Microsoft decided to only store crash data (minidumps) for crashes that the Microsoft reporting servers were collecting for.

     

    Did we screw it up?  I hope not.  Let us know if we did so we work on fixing it..

     

    Kind regards,

    -Jason

    Thursday, June 28, 2007 4:40 PM
  • aao123, Thanks for your post!!!  This was a decision that I personally did not agree with, but at the time I don't think there was enough evidence to account for the work to enable your scenario.  I completely understand the frustration I see in your post, and I feel you are owed an explanation on how we have arrived here.  To do that, I need to start at the beginning about 7 years ago.

     

    History... the ability to redirect Error Reports was implemented to mitigate the encounter of a scenario where users are behind a corporate firewall (say... a financial institution) and there are strict policies that govern what traffic is allowed to leave the corporate network.  A solution was to create a set of Error Reporting Group Policies that governed the WER client behavior, and gave the IT Admin control of the reporting by creating a WER Report 'broker' system called 'Corporate Error Reporting'.  The 'Broker' system was primitive since it talked SMB as a protocol and directly wrote files to a directory structure.  The solution was released as a resource kit tool, and later became one of the Software Assurance benefits for Client, Server, and Business Application channels. 

    The mindset of Microsoft at the time was to enable reports that were sent to Microsoft be the end-user to actually make their way to Microsoft and not get blocked at the Gateway leaving the corporate network.  This was not thought about in the context of helping developers by redirecting crashes local in unit testing or from internal betas. ...that was just a handy scenario that happened to be enabled.

     

    This part of the code was basically static over the years since there were no new requirements until the Operations Manager team started thinking about IT Pro scenarios around monitoring the reliability of the IT Desktop.

     

    Today... as different IT Management solutions matured and released new features, it became apparent that enabling an IT Admin to gain insight to reliability and availability of the desktop is interesting in addition to monitoring servers.  Enabling monitoring solutions around WER was just a natural progression (given the original intent of the existing protocol).  The solution was still aimed at IT PROs for value add while enabling reports to be shared with Microsoft through a Broker system.  This is where you feel you have run into a problem (because the new solution does not happen to enable the scenario for developers as the previous solution just happened to do).  The protocol changed to be more secure and scalable to meet the requirements of the Operations Manager team.  In doing so, the WER clients that leveraged the new protocol (http/https/SOAP) have orphaned the CER tool which is no longer in circulation or supported.

     

    Going forward (where you want this to go)... okay, that's the history.  Now lets talk about what Microsoft should do about enabling developers through WER redirection scenarios like the old CER solutions.  Would it be enough to create a stand-alone client that can talk the new protocol and behave like the old CER from a developer's point of view? 

    I would envision the answer is 'no'.  If we had a clear calling <hint!> for a Dev tool that managed WER reports (redirected from internal machines, and maybe even from the Winqual site where Winqual acted as a 'broker', we could prioritize releasing such a tool that enabled you to define your Symbol Server and Source, ...automatically processed the reported dump files and prioritized them based on a set of configurable rules and made them available through extensions to the IDE.  I think there is value in that personally but as history shows, we need to hear what our customers feel they need and then create solutions that are enabling based on the need.

     

    Call to action! 

    I would love someone to start a new thread and just rant (as much as possible) about what developers need from WER!  I would love it even more if everyone who passes through this forum left their thoughts in that thread.  Why?  Because it would hold clear evidence from the active community (verticles aside) that we need to offer more tools for our services around WER and evidence is what gets the funding.  Moreover, it will show the areas of immediate need that I can drive the WER teams towards.

     

    Kind regards,

    -Jason

    Friday, July 13, 2007 4:34 PM

All replies

  • David,

     

    on Vista, minidumps are transmitted only upon explicit demand from the server, at least that is how I understand it. Jason Hardester's post at http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1426737&SiteID=1 explains some of the rationale behind the server's decisions.

     

    You can force the system to always generate minidumps by enabling queuing mode: Set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ForceQueue (DWORD) to 1. Crash report data are stored in c:\Users\someusername\AppData\Local\temp and C:\ProgramData\Microsoft\Windows\WER\ReportQueue.

     

    Hope this helps,

     

      Claus

     

    http://www.clausbrod.de/Blog

     

     

    Tuesday, June 26, 2007 12:57 PM
  • Claus, thank you so much.  I set the ForceQueue and now the minidump is saved!  I really appreciate it.  I had seen doc of the ForceQueue but did not think it had anything to do with whether minidumps were created.

     

    Cheers,

    David

    http://www.dcsoft.com

     

    Tuesday, June 26, 2007 4:43 PM
  • OK, while setting ForceQueue to 1 does happily generate the minidump, now the user sees no UI of this happening.  Before, a dialog said

     

      <Program> has stopped working

        ...

       [Debug]   [Close Program]

     

     

    Is there a way to both generate the minidump AND have the dialog?

     

     

    Thanks,

    David

    Tuesday, June 26, 2007 5:24 PM
  • I used ForceQueue for debugging purposes only, and the fact that the dialogs didn't appear was acceptable in that scenario.

     

    If you register and map your app with the Winqual servers, then the servers will at least occasionally request minidump information from your app, and then you'll be able to download the minidumps from Winqual.

     

    Another option is to shut off the Internet connection when the crash occurs. The dialogs will then be displayed, but when WER finds out it cannot send stuff to the servers, it will archive the crash data (including minidumps) so that they can be re-sent at some later point in time.

     

    A variation of this idea is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\CorporateWERServer to the name of some machine in your network. When a crash occurs, WER will assume that a "Corporate Error Reporting" server is running on that box, and will try to talk to port 1273. If there's no answer, then WER will probably create the minidump and keep it around for later.

     

    Of course, you could also set up a real Corporate Error Reporting server which always requests the minidump information from the client. I haven't tried this myself yet, though.

     

    Claus

     

    http://www.clausbrod.de/Blog

     

     

    Tuesday, June 26, 2007 8:41 PM
  • Hi Claus,

     

    Yes, well, it would be much nicer to have the dialog when ForceQueue=1, because otherwise the user won't even know a crash has occurred until the program is noticed missing!  If the program has no UI, that is hard indeed. I appreciate your words on the workarounds, but only the Corporate server seems like the real deal.  (I can't imagine asking the user to unplug the Internet!).  That tidbit really came in handy on explaining what to do to get minidumps to work on Vista.

     

    Best,

    David

    Tuesday, June 26, 2007 11:22 PM
  • Oh, I see. My assumption was that you only need a setup for development purposes, not necessarily for end users.

     

    If you register and map your app at Winqual, then the Winqual servers will request minidump information basically whenever a "new" type of crash occurs, i.e. a type of crash which the servers don't know about yet. At least that's how I understand the theory behind it, and if it works in practice as well, it means you as a developer will be able to get all required crash information from the Winqual servers.

     

    If you don't want to go through Microsoft, and the code in question is for an in-house application for which you have some control over its deployment, CER/AEM becomes a viable option, i.e. install an error reporting server within in the company.

     

    But maybe Saar or Jason have some additional ideas about configuration or registry options which help to accomplish what you want?

     

    Claus

     

    http://www.clausbrod.de/Blog

     

    Wednesday, June 27, 2007 6:33 AM
  • It seems MS means for us to use Winqual servers or the corporate error reporting servers as the only means of getting the minidumps to the developers, and for some of my clients, these suit the bill just fine.  But for smaller shops, they do just fine sneaker-netting the minidump from QA to the developer, and it seems this sneaker-net idea is not as good with the new Windows Error Reporting way of doing things. 

    I was tasked to author a tutorial on minidumps, and to be honest, I'm not sure if my audience will prefer the traditional Dr. Watson way, or the new WER way.  But it would have been nice if the Dr. Watson way had been totally preserved within WER, for the people who prefer to do it that way.

     

    Thanks again for all your good info.

     

    -- David

     

    Wednesday, June 27, 2007 5:41 PM
  • Just a wild idea which I'm sure Jason may not like so much (and I understand why) :

    • Call SetUnhandledExceptionFilter to register your own top-level exception filter code.
    • In that exception filter, call MiniDumpWriteDump to create a minidump file of your own describing the crash.
    • Return from the filter with EXCEPTION_CONTINUE_SEARCH.

    Check out http://www.clausbrod.de/Blog/DefinePrivatePublic20070627 for some demo code! 

     

    Cheers,

     

      Claus

     

     

     

     

    Wednesday, June 27, 2007 7:47 PM
  • HI Claus,
       I tried setting the reg key "ReportQueue" but still my application did not create a minidump file on vista. Am i missing any project settings ...?
    Wednesday, June 27, 2007 10:33 PM
  • The registry value name is "ForceQueue", not "ReportQueue". See http://msdn2.microsoft.com/en-us/library/aa363489.aspx for Microsoft's documentation on WER-related registry settings. (Those registry keys, by the way, are completely independent from the MiniDumpWriteDump() demo code I posted.)

     

    Hope this helps,

     

    Claus

     

    Thursday, June 28, 2007 4:48 AM
  • Claus, thanks.  This is a valid option, but the whole point of Dr. Watson and WER is so we don't have to alter our code at all to get minidumps!  I'm sure MS didn't mean to screw up WER so bad that it forces developers to write their own minidumps! 

     

    Cheers,

    David

    Thursday, June 28, 2007 4:59 AM
  • Hi David,

     

    What Operating Systems are you creating minidump tutorials for?  The behavior is different in Windows Vista than it is in older operating systems.

     

    Let me address various ways to get minidumps on the local machines for 'sneaker-net' and then direct you to what we had envisioned.

     

    Sneaker-net

    If you map your files on winqual, we will put the server into collection mode for your file's crashes.  This is interesting to you for the sneaker-net approach since minidumps are only stored locally in Windows Vista if the servers were collecting data at the time of the report.  (...also, I believe the minidump will be available if the computer is offline)

    Sneaker-net approach for older operating systems is easy... set up CER policies to report crash information to a local folder or shared folder, and have the 'Cabs' folder sent to you via whatever transport = sneaker-net.  You don't need to change your code, but you do need to be aware of expected client side behavior to be successful in the sneaker-net approach.  For example, CER is not supported in Windows Vista.  Instead, AEM is the method to use (the protocol is different).  AEM requires Operations Manager 2007, so there is overhead for an IT shop if they are not already leveraging this technology whereas CER was overly simple.  On Windows Vista, there is another solution (target's end-users) called Problem Reports and Solutions ...or wercon.exe.  If the back-end services were collecting data for the crash, the same data is available through wercon.exe.

     

    What Microsoft had envisioned

    For Developers - We had envisioned developers and ISVs to use Winqual to access crash information by mapping their products/files.  In this way, it did not matter where the report came from; Winqual would prioritize failures based on volume and growth of the reports over 90 days and enable developers and ISVs to create responses that would be displayed tot eh users if they encountered the crash again with information that could prevent the crash (update available, workaround, and so on).  Error Reporting for Applications happens by default without any needed application code unless the application is handling their own exceptions (...and as Claus mentioned, I don't encourage anyone to implement their own exception handler). 

     

    For IT-PROs - We had also envisioned the need for IT-Professionals (System/Network  administrators of companies) to manage what should be allowed to leave the corporate wire in regards to error reporting.  To achieve this management in the past, we offered Corporate Error Reporting.  This was a set of client policies and a tool that redirected error reports from within the IT shop to a common location where the Admin could use the tool to configure common reporting behavior and broker the data to Microsoft for the types of data the Admin allowed. (See CER).  This solution was not scalable for large IT-PRO shops as the tool used local memory to load the crash data in the common folder and apply the reporting rules.  The larger the share size and # of unique reports the longer it would take to load and report.  For Windows Vista,   it was decided to change the reporting protocol to use http/https and interact with Operations Manager 2007 using AEM (Agentless Event Management).

     

    For End Users - Finally, we had envisioned that it would be useful for an end-user top see (historically) what Error Reporting events happened on their computer.  To enable this, we created wercon.exe.  Through this tool, users can not only see what happened in the past, but they can check for solutions (responses) without having to wait for the crash to happen again.  The tool does keep crash data around in a queue so to prevent unneeded utilization of disk space Microsoft decided to only store crash data (minidumps) for crashes that the Microsoft reporting servers were collecting for.

     

    Did we screw it up?  I hope not.  Let us know if we did so we work on fixing it..

     

    Kind regards,

    -Jason

    Thursday, June 28, 2007 4:40 PM
  • Hi Jason,

     

    Thank you very much for taking the time to write this thorough response!  I very much appreciate it.  The tutorial I am creating covers crash dumps on XP and Vista, and the target audience is for ISV developers.  In all of the small-medium sized ISV shops (e.g. 5-10 developers) I have worked with, not one of them has set up servers to handle crash dumps.  If the QA dept found a crash, then they would attach the minidump file to the bug report, and the developer would take it from there.  In XP, simply setting up DrWtsn32 to specify the folder where the dump file would be placed is all that is necessary.  This works really well.  So I wish that WER still made this easy.

    I hear you about how we're supposed to use Winqual, and to be honest, I have not used it, so it may be easier than I think.  It's unclear to me whether Winqual is meant to be used for pre-release software?  I think I read it requires a Verisign signing cert.  Why is that?  My signing cert is not from Verisign, it's from Comodo because it's way cheaper.  In any event, registering for Winqual seems overkill when internal QA depts are more than capable of managing their own minidumps the sneaker-net way.

      It seems a half-hearted attempt was made to preserve that way with the ForceQueue reg key; however, since it disables the dialog that notifies of a crash, it's not very usable.  Could you fix it so that it doesn't disable the dialog?

    Also, does CER == Dr. Watson; because AFAIK, Dr. Watson does not use "cabs"? 

    If I could give you some feedback, it's that the message of how to use WER is not exactly crystal clear; it seems Microsoft as a company seems to have given up on even trying to get a crystal clear message about how to use their new technologies, instead relying on grassroots efforts like this forum, blogs, etc.  I'm thrilled those exist, and doubly thrilled for your and Claus' presence and heroic effort, but really, shouldn't the official doc writers be capable of explaining these things?

     

    Best,

    David

    Thursday, June 28, 2007 11:21 PM
  • > Did we screw it up?  I hope not.  Let us know if we did so we work on fixing it.

    We do map our products and files with winqual, and this provides very useful information, but there are a couple of circumstances where this is insufficient:

    a) When a customer needs immediate support, or needs to provide us with extra information (e.g. sample data) along with the problem report

    b) When the minidump does not enough information, and we need a full dump including the heap to diagnose the fault

    In the past we have asked users in this situation to use Dr Watson to collect a full crash dump, and get it to us via CD-R or ftp or something. What should we ask customers using Vista to do?

    Thanks for any advice!
    Friday, June 29, 2007 12:04 PM
  • Thanks David,

     

    I agree with you.  I also have agreement from the WER client and Vista Logo teams as well that this is a problem.  We will be updating our documentations.  We are also looking into creating code samples, Et Al to make things very clear and simple.  Thanks for your feedback!

     

    I'll post some materials that will help you in creating your documentation over the next few days.

     

    Kind regards,

    -Jason

    Friday, June 29, 2007 12:51 PM
  • Thanks for the feedback!  I have some good news for you...

     

    We have plans to enable data collection (outside of the APIs in WER) through the WER Service.  In this way, you will be able to register through the service what you need to collect, and the next report will contain that data.  This also applies to types of dumps to collect (mini, mini+HEAP, Full, Kernel, etc). 

     

    To be clear, your applications that you author today can use the WER APIs to collect extra data, but that requires planning since you need to code what to collect in your product.  The solution we are planning on providing is service initiated, so it's reactive and requires registration of the data collection through the WER Services.

     

    I don't have a timeline to share with you, and we are prioritizing our web service interfaces over this work.  ...but we know how to do it; it's just a matter of getting to that work.  It may be possible that you will see web services and service side data collection registration released before the end of the calendar year.

     

    Kind regards,

    -Jason

     

    Friday, June 29, 2007 1:02 PM
  • Thank you for the reply. I can see how the WER APIs allow me to control the amount of information included in the error report, but I don't understand whether they (or some future service side equivalent) address the following scenario...

    A customer of ours provokes a crash in our application, and phones or emails our support line. Depending on the nature of the problem we may need to ask them to generate either a without-heap or a with-heap mdmp file and send it to us. We may also want to ask for a description of what they were doing at the time, and for some or all of the data files involved. When we've finished, we may want to get back to them with a workaround.

    Since the removal of Dr Watson from Windows Vista, there appears to be no way for a customer to generate the mdmp files directly, and using the WER mechanism instead to upload the report to Microsoft's servers has the following problems:
    1. There doesn't seem to be a way for a customer (with their consent of course) to include their contact information with the fault report. This makes it difficult or impossible to connect a particular mdmp file with the customer's support call.
    2. A full with-heap mdmp file, which we sometimes need to diagnose a problem, is often several hundred MB in size; so a CD-R or ftp based mechanism may well be more practical than going via winqual.
    3. The winqual mechanism seems to impose delays of days to weeks in making crash dump information available to us. This is not appropriate in cases where the customer needs immediate support.
    Have I missed something? The only solution I can currently see is to add exception handling code, and write the dump file ourselves; obviously I'd rather not do that!
    Friday, June 29, 2007 5:05 PM
  • Yup, all we'd need is, say, a ForceMinidump registry key, or (better, of course) an equivalent setting in the Problem History UI. That should address many of the situations as described by JPSA.

     

    While I understand why people in general try to stay away from adding crash handlers to their code, it is actually fairly easy to do, plays well with WER, and doesn't have to violate the "an application which is doomed to crash shall terminate immediately" mantra, as demonstrated at http://www.clausbrod.de/Blog/DefinePrivatePublic20070627. Twenty lines of code, and your app has minidump support when you need it, regardless of which operating system you're running on.

     

    Oh, by the way, apparently you can still run Dr Watson even on Vista: http://www.dumpanalysis.org/blog/index.php/2007/05/19/resurrecting-dr-watson-on-vista/

     

    Claus

     

    Friday, June 29, 2007 8:33 PM
  • Thanks Jason.  My tutorial is a video that shows using Dr. Watson on XP and using the Control Panel applet in Vista, then it shows how to set the ForceQueue reg key to make sure the minidump is generated.  Finally, it shows the Corporate server reg key, in case the user wants to setup a corporate server for the minidumps.  Those seem like the best alternatives at the moment, buy I'm excited about the planned enhancements you have shared.

     

    Best,

    David

    Saturday, June 30, 2007 12:38 AM
  • > Oh, by the way, apparently you can still run Dr Watson even on Vista: http://www.dumpanalysis.org/blog/index.php/2007/05/19/resurrecting-dr-watson-on-vista/

     

    Ooof, if only Vista hadn't deleted Dr. Watson!

     

    -- David

     

     

    Saturday, June 30, 2007 12:39 AM
  • Well, apparently you can simply copy good ol' Dr Watson over from some XP machine.

     

    Yet another alternative: Write some minimal JIT debugger code and deploy the JIT debugger on the test machines. When a crash occurs, have the user/tester hit the "Debug" button to produce and send minidumps using the special JIT debugger. This way, you don't have to add any crash handler logic to applications.

     

    Claus

     

    Saturday, June 30, 2007 7:56 AM
  • > http://www.clausbrod.de/Blog/DefinePrivatePublic20070627. Twenty lines of code, and your app has minidump support when you need it, regardless of which operating system you're running on.

     

     

    Nice summary of the discussion here.  Thanks for blogging this, Claus! 

     

    It had not occurred to me that if you set an exception handler, you could return EXCEPTION_CONTINUE_SEARCH so the the default WER would still be enabled. I had thought your exception handler would *replace* the WER.  So thanks for pointing this out, and I agree this is a good workaround for the fact that currently Vista does not truly support a Dr. Watson-like experience.

     

    Cheers,

    David

    Saturday, June 30, 2007 2:43 PM
  •  

    > Yet another alternative: Write some minimal JIT debugger code and deploy the JIT debugger on the test machines. When a crash occurs, have the user/tester hit the "Debug" button to produce and send minidumps using the special JIT debugger. This way, you don't have to add any crash handler logic to applications.

     

    Well yes, and I guess you would then have a Dr. Watson! 

     

    Cheers,

    David

    Saturday, June 30, 2007 2:45 PM
  • It's true, such a utility would in fact be a stripped-down version of Dr Watson.

     

    In fact, wondering how difficult it could actually be to write such code, I slapped together a couple of lines, and now I've got a prototype of such a tool. Thanks for the inspiration! Expect a new blog posting early next week

     

    Claus

     

    http://www.clausbrod.de/Blog

     

    Saturday, June 30, 2007 3:56 PM
  • In the meantime, I have found yet another workaround. Actually, this time it's such a convenient workaround that you may even call it a fix for the minidump deprivation issue.

    The magic three words are "Create Dump File", and the Task Manager is our friend! Details at http://www.clausbrod.de/Blog/DefinePrivatePublic20070630

    Cheers,

     Claus

    Sunday, July 01, 2007 12:18 PM
  • Hi Claus,

    Nice find!  Actually, I had read this KB article before but had ignored it because it creates a "user dump" and not a "mini dump".  I had thought the user dump includes all heap (equivalent to setting Dump Type:  Full in Dr. Watson on XP) which leads to gigantic dump files.  But maybe if it puts the heap in .hdmp and the minidump in .mdmp, then maybe we can instruct the user to just send the .mdmp?  Does it do this?

    Also, the Create Dump File option is available in Task Manager regardless of whether the app has crashed or not.  That's another reason I didn't think the KB article applied to post-mortem debugging.  It seems weird to create a Dump File when the app has not crashed!  Very strange.

    So anyway, as you say, the user can set up WER to prompt so that the dialog appears and the user then knows a crash occurs (good), then at that time they open Task Manager, find their process, and Create Dump File (good).  I would say this is somewhat inconvenient and error prone, so there is still use for your Dr. Watson replacement utility.

    Have you investigated AdPlus, which the KB article references?  It's part of Debugging Tools for Windows, but I could not find any easily accessible documentation.

     

    Thanks,

    David

    Sunday, July 01, 2007 8:48 PM
  • David,

    I used ADplus a couple of years ago to investigate crashes on a customer machine (with some success, in fact). Back then, ADplus was a VBscript program on top of cdb or ntsd (don't remember exactly) which attaches to a process with is either hanging or about to crash, and then collects information from that process. I used to the MSKB article at http://support.microsoft.com/kb/286350 as a reference on this tool.

    Claus

    http://www.clausbrod.de/Blog

    Monday, July 02, 2007 6:19 AM
  • Alright - beta testers wanted for my Dr. Watson wanna-be code: Check out http://www.clausbrod.de/Blog/DefinePrivatePublic20070703

     

    Cheers,

     

      Claus

     

    Tuesday, July 03, 2007 6:55 AM
  • Jason I have a question - what is the MS rational behind removing useful features from Windows? You do not seriously believe that AEM approach is useful for any body who's IT does not have hundreds of people, do you? At the time when we, developers , struggle to convince our management not to switch to Linux, you at Microsoft taking away the very tools we use every day, not to mention additional load on our IT departments.  Who the hell makes such decisions at Microsoft?

    Wednesday, July 11, 2007 1:54 PM
  • Jason I have a question - what is the MS rational behind removing useful features from Windows? You do not seriously believe that AEM approach is useful for any body who's IT does not have hundreds of people, do you? At the time when we, developers , struggle to convince our management not to switch to Linux, you at Microsoft taking away the very tools we use every day, not to mention additional load on our IT departments.  Who the hell makes such decisions at Microsoft?

    Wednesday, July 11, 2007 2:08 PM
  • Jason I have a question - what is the MS rational behind removing useful features from Windows? You do not seriously believe that AEM approach is useful for any body who's IT does not have hundreds of people, do you? At the time when we, developers , struggle to convince our management not to switch to Linux, you at Microsoft taking away the very tools we use every day, not to mention additional load on our IT departments.  Who the hell makes such decisions at Microsoft?

    Wednesday, July 11, 2007 2:27 PM
  • Thanks to all who replied. The new task manager "Create Dump File" feature (which I hadn't noticed until Claus kindly pointed it out) will suffice for our purposes, I think.
    Wednesday, July 11, 2007 2:55 PM
  • To me, this looks just like an oversight, and it can probably (and hopefully) be fixed easily. Fortunately, there are several viable approaches for workarounds on Vista (see my latest summary at http://www.clausbrod.de/Blog/DefinePrivatePublic200707 for details).

     

    Since AEM (Agentless Exception Monitoring) is one of the options to get our beloved crashdumps back , has anybody here tried it yet? I've been meaning to install the evaluation version (http://www.microsoft.com/downloads/details.aspx?FamilyID=5d9d0b53-2320-4504-b079-72292b1a81d0&displaylang=en), but haven't gotten around to do that yet. The system requirements are a little deterring; apparently, Windows Server 2003 SP2 is the only supported platform, so I'm not sure I'll be able to even install it on some plain vanilla XP or Vista test system to play with it. Well, I guess I'll head over to the MOM newsgroups at http://www.microsoft.com/technet/community/newsgroups/server/mom.mspx to find out more...

     

    Cheers,

     

    Claus

     

     

     

     

     

    Wednesday, July 11, 2007 8:58 PM
  • aao123, Thanks for your post!!!  This was a decision that I personally did not agree with, but at the time I don't think there was enough evidence to account for the work to enable your scenario.  I completely understand the frustration I see in your post, and I feel you are owed an explanation on how we have arrived here.  To do that, I need to start at the beginning about 7 years ago.

     

    History... the ability to redirect Error Reports was implemented to mitigate the encounter of a scenario where users are behind a corporate firewall (say... a financial institution) and there are strict policies that govern what traffic is allowed to leave the corporate network.  A solution was to create a set of Error Reporting Group Policies that governed the WER client behavior, and gave the IT Admin control of the reporting by creating a WER Report 'broker' system called 'Corporate Error Reporting'.  The 'Broker' system was primitive since it talked SMB as a protocol and directly wrote files to a directory structure.  The solution was released as a resource kit tool, and later became one of the Software Assurance benefits for Client, Server, and Business Application channels. 

    The mindset of Microsoft at the time was to enable reports that were sent to Microsoft be the end-user to actually make their way to Microsoft and not get blocked at the Gateway leaving the corporate network.  This was not thought about in the context of helping developers by redirecting crashes local in unit testing or from internal betas. ...that was just a handy scenario that happened to be enabled.

     

    This part of the code was basically static over the years since there were no new requirements until the Operations Manager team started thinking about IT Pro scenarios around monitoring the reliability of the IT Desktop.

     

    Today... as different IT Management solutions matured and released new features, it became apparent that enabling an IT Admin to gain insight to reliability and availability of the desktop is interesting in addition to monitoring servers.  Enabling monitoring solutions around WER was just a natural progression (given the original intent of the existing protocol).  The solution was still aimed at IT PROs for value add while enabling reports to be shared with Microsoft through a Broker system.  This is where you feel you have run into a problem (because the new solution does not happen to enable the scenario for developers as the previous solution just happened to do).  The protocol changed to be more secure and scalable to meet the requirements of the Operations Manager team.  In doing so, the WER clients that leveraged the new protocol (http/https/SOAP) have orphaned the CER tool which is no longer in circulation or supported.

     

    Going forward (where you want this to go)... okay, that's the history.  Now lets talk about what Microsoft should do about enabling developers through WER redirection scenarios like the old CER solutions.  Would it be enough to create a stand-alone client that can talk the new protocol and behave like the old CER from a developer's point of view? 

    I would envision the answer is 'no'.  If we had a clear calling <hint!> for a Dev tool that managed WER reports (redirected from internal machines, and maybe even from the Winqual site where Winqual acted as a 'broker', we could prioritize releasing such a tool that enabled you to define your Symbol Server and Source, ...automatically processed the reported dump files and prioritized them based on a set of configurable rules and made them available through extensions to the IDE.  I think there is value in that personally but as history shows, we need to hear what our customers feel they need and then create solutions that are enabling based on the need.

     

    Call to action! 

    I would love someone to start a new thread and just rant (as much as possible) about what developers need from WER!  I would love it even more if everyone who passes through this forum left their thoughts in that thread.  Why?  Because it would hold clear evidence from the active community (verticles aside) that we need to offer more tools for our services around WER and evidence is what gets the funding.  Moreover, it will show the areas of immediate need that I can drive the WER teams towards.

     

    Kind regards,

    -Jason

    Friday, July 13, 2007 4:34 PM