Options

Still getting thread aborted error in Event Log with 5.1

MikeyCMikeyC Posts: 249 Bronze 3
A number of bugs have been fixed, including:
  • Prevented misleading Thread was being aborted message from being added to log

It looks like there are still thread aborted errors in 5.1.4.11, though they look like they are different than the ones I was getting before:

Event Type: Error
Event Source: SQL Prompt 5
Event Category: None
Event ID: 0
Date: 4/12/2011
Time: 10:59:52 AM
User: N/A
Computer: <snip>
Description:
2011-04-12 10:59:52,174 [8] ERROR RedGate.SqlPrompt.Engine.LogService [(null)] - LogService caught unhandled exception in AppDomain: 'Thread was being aborted.'
System.Threading.ThreadAbortException: Thread was being aborted.
at RedGate.SQLPrompt.CommonUI.TaskExecuter.Executer.

Comments

  • Options
    I'll ask a developer to take a look at this.

    Luke Jefferson
    Product Manager
    Red Gate Software
    E: luke.jefferson@red-gate.com
  • Options
    acrawfordacrawford Posts: 13 Bronze 2
    I'm getting the exact same error; Windows 7 Pro 64 bit. Does this have anything to do with the RedGate.IPNService? What is this service for? It sits and takes 17-20mb of memory.
  • Options
    benreesbenrees Posts: 16 Bronze 1
    Thanks for your feedback. We’ve looked in to this and you can ignore the error (we’re going to fix the next version, so that we’re less zealous with error messages!). The IPN Service is part of the Check for Updates process, installed with Red Gate products, and helps ensure you have the latest releases and to keep your support and upgrades up-to-date (if relevant).

    Ben Rees
    Product Manager
    Red Gate Software
  • Options
    benrees wrote:
    The IPN Service is part of the Check for Updates process, installed with Red Gate products, and helps ensure you have the latest releases and to keep your support and upgrades up-to-date (if relevant).

    Ben Rees
    Product Manager
    Red Gate Software

    Wonderful. Yet another software package that wants to run its own update service continuously. It would be FAR MORE FRIENDLY to simply check once a day using a scheduled task, or to check ONCE when a product is started. Instead you've raised the overhead of using your (admittedly excellent) products by 44mb at best (when everything is working) and by a full core's worth of CPU at worst (when it isn't).

    Is the operation of SQL Prompt and other products absolutely dependent on this running? Is there any chance of changing the minds of your development team?
Sign In or Register to comment.