Delphi XE8 Random IDE crashes

For the first time in recent memory, my Delphi IDE is just plain
unstable.  I'm using XE8 Update 1 and of course, with /NOCASTALIA. I
have removed everything I can from Delphi and still use it (no IDE
plugins, etc).  I've only recently begun using XE8 (as in the last few
weeks.)  I am only working with VCL projects.
Obviously this is not a place to post bug reports.
But even if it were, I couldn't.
When the IDE crashes, there is NO useful information.
When I distribute my own applications, I use MadExcept so that users
can provide me with useful information if something goes wrong.
I wish Embarcadero did something like that.
Good thing I have the habit of typing CTRL+S all the time.  So far, I
have only lost a little but of work product.
:-/
-- 
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com

Brandon wrote:
> Obviously this is not a place to post bug reports.
No.  They need to be reported to QualityPortal.
> When the IDE crashes, there is NO useful information.
> 
> When I distribute my own applications, I use MadExcept so that users
> can provide me with useful information if something goes wrong.
> 
> I wish Embarcadero did something like that.
They used to, when QualityCentral was the primary bug reporting system.  
QualityCentral was integrated directly into the IDE in such a way that an 
IDE crash would generate an automatic bug report with a crash dump, stack 
trace, etc and then the user was prompted whether to submit it to QualityCentral 
or not.  Now that Embarcadero has switched to QualityPortal as the new bug 
reportng system, that same integration has not been implemented yet, as QualityPortal 
does not have a WebService interface like QualityCentral does.
-- 
Remy Lebeau (TeamB)

"Remy Lebeau" wrote on Mon, 13 Jul 2015 12:19:13 -0700:
> They used to, when QualityCentral was the primary bug reporting system.  
> QualityCentral was integrated directly into the IDE in such a way that an 
> IDE crash would generate an automatic bug report with a crash dump, stack 
> trace, etc and then the user was prompted whether to submit it to QualityCentral 
> or not.  Now that Embarcadero has switched to QualityPortal as the new bug 
> reportng system, that same integration has not been implemented yet, as QualityPortal 
> does not have a WebService interface like QualityCentral does.
Unfortunately this means that crashes that can't be reproduced with a
simple project must be experienced by the QA team.  How am I supposed
to report an IDE crash when I can't reproduce it reliably, without a
stack trace?
...... Just frustrated.
-- 
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com

> {quote:title=Brandon Staggs wrote:}{quote}
> Good thing I have the habit of typing CTRL+S all the time.  So far, I
> have only lost a little but of work product.
> 
> :-/
Try to use FreePascal and Lazarus. IMO It's more stable and professional. Programming in Delphi became a nightmare.

> 
> When the IDE crashes, there is NO useful information.
> 
I had the same problem after updating to Update 1. The few times I did get info on the crashes, it mentioned the Start page. So I prevented startpageide140.bpl from loading and have not crashed since.
Rick Hollerich

Brandon Staggs wrote:
> How am I supposed
> to report an IDE crash when I can't reproduce it reliably, without a
> stack trace?
Have you tried madExcept Tools->madExcept config->Enable IDE exception
catching?
--
Alex

> So I prevented startpageide140.bpl from loading and have not crashed 
> since.
With XE8 the it should be $(BDS)\Bin\startpageide220.bpl
Ronald

> So I prevented startpageide140.bpl from loading and have not crashed 
> since.
With XE8 the it should be $(BDS)\Bin\startpageide220.bpl
Ronald

"Brandon Staggs" <nospam@nowhere.invalid> wrote in message 
news:728235@forums.embarcadero.com...
> "Remy Lebeau" wrote on Mon, 13 Jul 2015 12:19:13 -0700:
>
>> They used to, when QualityCentral was the primary bug reporting system.
>> QualityCentral was integrated directly into the IDE in such a way that an
>> IDE crash would generate an automatic bug report with a crash dump, stack
>> trace, etc and then the user was prompted whether to submit it to 
>> QualityCentral
>> or not.  Now that Embarcadero has switched to QualityPortal as the new 
>> bug
>> reportng system, that same integration has not been implemented yet, as 
>> QualityPortal
>> does not have a WebService interface like QualityCentral does.
>
> Unfortunately this means that crashes that can't be reproduced with a
> simple project must be experienced by the QA team.  How am I supposed
> to report an IDE crash when I can't reproduce it reliably, without a
> stack trace?
>
How?
There are (external) means (or at least used to be) to extract 
dumps/minidumps while the application is still "alive" tho' effectively 
inoperative, but when I did this and inquired about interest, I got 
absolutely zero response, (IIRC) 8-9 years ago.
I suppose you could try and see if anything has changed in that regard since 
then.
At least one of Allen's blog posts indicates spelunking into the depths of 
windows (TMonitor, exponential backoff), so I expect that at least he is 
capable of analyzing them if they have any interest in expending the effort.

"david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:728297@forums.embarcadero.com...
> "Brandon Staggs" <nospam@nowhere.invalid> wrote in message 
> news:728235@forums.embarcadero.com...
>> "Remy Lebeau" wrote on Mon, 13 Jul 2015 12:19:13 -0700:
>>
>>> They used to, when QualityCentral was the primary bug reporting system.
>>> QualityCentral was integrated directly into the IDE in such a way that 
>>> an
>>> IDE crash would generate an automatic bug report with a crash dump, 
>>> stack
>>> trace, etc and then the user was prompted whether to submit it to 
>>> QualityCentral
>>> or not.  Now that Embarcadero has switched to QualityPortal as the new 
>>> bug
>>> reportng system, that same integration has not been implemented yet, as 
>>> QualityPortal
>>> does not have a WebService interface like QualityCentral does.
>>
>> Unfortunately this means that crashes that can't be reproduced with a
>> simple project must be experienced by the QA team.  How am I supposed
>> to report an IDE crash when I can't reproduce it reliably, without a
>> stack trace?
>>
>
> How?
You could also try running the IDE under the IDE, and see if you can get any 
sort of stack trace, or anything, perhaps on a first-chance exception.

"david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:728298@forums.embarcadero.com...
> "david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
> news:728297@forums.embarcadero.com...
>> "Brandon Staggs" <nospam@nowhere.invalid> wrote in message 
>> news:728235@forums.embarcadero.com...
>>> "Remy Lebeau" wrote on Mon, 13 Jul 2015 12:19:13 -0700:
>>>
>>>> They used to, when QualityCentral was the primary bug reporting system.
>>>> QualityCentral was integrated directly into the IDE in such a way that 
>>>> an
>>>> IDE crash would generate an automatic bug report with a crash dump, 
>>>> stack
>>>> trace, etc and then the user was prompted whether to submit it to 
>>>> QualityCentral
>>>> or not.  Now that Embarcadero has switched to QualityPortal as the new 
>>>> bug
>>>> reportng system, that same integration has not been implemented yet, as 
>>>> QualityPortal
>>>> does not have a WebService interface like QualityCentral does.
>>>
>>> Unfortunately this means that crashes that can't be reproduced with a
>>> simple project must be experienced by the QA team.  How am I supposed
>>> to report an IDE crash when I can't reproduce it reliably, without a
>>> stack trace?
>>>
>>
>> How?
>
> You could also try running the IDE under the IDE, and see if you can get 
> any sort of stack trace, or anything, perhaps on a first-chance exception.
Perhaps run the 'upper' IDE (the one being used to debug the IDE instance 
you use) with -r, and having nothing installed in whatever registry branch 
you specify...

"david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:728298@forums.embarcadero.com...
> "david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
> news:728297@forums.embarcadero.com...
>> "Brandon Staggs" <nospam@nowhere.invalid> wrote in message 
>> news:728235@forums.embarcadero.com...
>>> "Remy Lebeau" wrote on Mon, 13 Jul 2015 12:19:13 -0700:
>>>
>>>> They used to, when QualityCentral was the primary bug reporting system.
>>>> QualityCentral was integrated directly into the IDE in such a way that 
>>>> an
>>>> IDE crash would generate an automatic bug report with a crash dump, 
>>>> stack
>>>> trace, etc and then the user was prompted whether to submit it to 
>>>> QualityCentral
>>>> or not.  Now that Embarcadero has switched to QualityPortal as the new 
>>>> bug
>>>> reportng system, that same integration has not been implemented yet, as 
>>>> QualityPortal
>>>> does not have a WebService interface like QualityCentral does.
>>>
>>> Unfortunately this means that crashes that can't be reproduced with a
>>> simple project must be experienced by the QA team.  How am I supposed
>>> to report an IDE crash when I can't reproduce it reliably, without a
>>> stack trace?
>>>
>>
>> How?
>
> You could also try running the IDE under the IDE, and see if you can get 
> any sort of stack trace, or anything, perhaps on a first-chance exception.
You could also try installing the full debug version of FastMM.  If the IDE 
is still dependent on dynamic runtime, then it should be loaded for IDE 
usage.
IIRC, for me, with 2006, this revealed two corruptions by the form editor 
almost immediately, although it never resulted in my receiving any sort of 
fix for the issue(s).
And these overwrites were very consistent, although the subsequent failing 
behavior did not always look quite the same.

"david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:728299@forums.embarcadero.com...
>
>>> How?
>>
>> You could also try running the IDE under the IDE, and see if you can get 
>> any sort of stack trace, or anything, perhaps on a first-chance 
>> exception.
>
> Perhaps run the 'upper' IDE (the one being used to debug the IDE instance 
> you use) with -r, and having nothing installed in whatever registry branch 
> you specify...
And one more thought, if IDE doesn't function to debug itself,
then might try the cdb debugger from the Microsoft debugging tools for 
windows.

From the archives, so you can know some of us feel your pain...
And one add'l bit of *OLD* information that may still be enlightening, and 
suggest use of CDB (since I think there is no .net debugger perse since ???) 
as a better alternative for some problems...
"Brandon Staggs" <nospam@nowhere.invalid> wrote in message 
news:728235@forums.embarcadero.com...
>
> ..... Just frustrated.
>
This is a part one email I sent to David Dean (2007/04/24) when he was 
working on builder QC/QA...
**For me to attempt (even if my boss allowed) to allow anyone to watch me, 
would be just a waste of time for me and them, particularly since I can't 
apply the builds in question to work I need to get done.  I have provided 
stack traces, and I have offered to provide memory dumps, that could be used 
to explore the context of actual problems that have occurred.  It is 
extremely frustrating to me that B/CG personnel are either unable or 
un-willing to examine those contexts.  In the past two weeks, about 3 times, 
I have had that [RANT] stupid [/RANT] editor assert trigger.  (I recently 
added an additional comment to the QC item, as these last 3 seem to have 
triggered around the type-ahead entry of a new line that has not yet been 
displayed.)  Without looking, I'm pretty sure that it was at least 6 months 
between when I submitted that original problem, and the next time it 
occurred.  I doubt your staff or management has extended periods of time to 
allocate, and I know I don't, to watching/playing with a beta environment 
until something happens.  I'm equally confident that they're pretty unlikely 
to observe a pattern that I've missed in "the way I work."  I expect I 
generally work the same way, and the manifestations themselves vary, 
repeating themselves in un-predictable, seemingly random, order.
From another email possibly useful IDE debugging info (tho' touched on in 
earlier posts):
> I have, however, managed to cajole out of R&D some suggestions and
> information which /may/ help. .Net exceptions are not trapped by the  code
> which produces the automated incident reports. You can run the  IDE using
> the .Net debugger so that when you get a crash that comes  from the .Net
> side, instead of the IDE simply dying, you should be  able to get us some
> usable stack traces.
> They also suggested that you try using the debug version of the  FastMM
> memory manager: <http://sourceforge.net/projects/fastmm> It  can catch and
> log some of the errors which also fail to trigger the  automated reports.
Remember that is *old* information, its current relevance is unknown.

"Alex Belo" wrote on Mon, 13 Jul 2015 21:32:48 -0700:
> Have you tried madExcept Tools->madExcept config->Enable IDE exception
> catching?
Yes, it's enabled.  Whatever is happening in the IDE is not getting
caught by MadExcept.
-- 
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com

"Brandon Staggs" <nospam@nowhere.invalid> wrote in message 
news:728343@forums.embarcadero.com...
>
> Yes, it's enabled.  Whatever is happening in the IDE is not getting
> caught by MadExcept.
>
Possibly then, a .Net exception of some sort, possibly not caught by 
MadExcept (I know little about it), that might be caught/trapped by a .Net 
capable debugger (as mentioned in my other recent posts)...

"Richard Hollerich" wrote on Mon, 13 Jul 2015 16:16:41 -0700:
>> 
>> When the IDE crashes, there is NO useful information.
>> 
> 
> I had the same problem after updating to Update 1. The few times I did get info on the crashes, it mentioned the Start page. So I prevented startpageide140.bpl from loading and have not crashed since.
After reading this I got into the habit of closing the welcome tab
after loading up Delphi, and since then, no random crashes.
My guess is an exception somewhere around the web browser component.
-- 
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com