I've also been experiencing this issue with Chromium builds going back at least a week if not two weeks.  Added a crash dump.

chrome.dmp 57.7 KB   Download

I have had it crash on 6.0.458.1 since it updated today on my two work machines (XP SP3 and 2008 x64). The homepage it opens is an internal site that I believe is using NTLM authentication. 6.0.458.1 works fine on my home PC that doesn't use that site. Attached is the crash log.

Does anyone have a work-around for restarting the browser without loading the default homepage? As it is, I cannot get Chrome to open, because it defaults to opening this internal web site, which causes it to crash immediately. I had to resort to IE at work for the remainder of the day!

crash.zip 81.0 KB   Download

I'm experiencing this issue too!! :-/

Windows 7 Professional, 32-bit

It happens when I try to go to the internal address of our Sharepoint site, which uses NTLM authentication. 

Very interesting thing that I've noticed, is that if I access it through the EXTERNAL url, which would USUALLY ask me for my username and password, it immediately lets me in via NTLM authentication and works just fine.

ODD.

I was playing around some more with the external facing DNS name that I could access for our intranet, and noticed that as soon as I clicked a link that took me to a page with an invalid certificate, EVEN on the external page, it immediately crashed.

So I'm guessing it's something messed up between certificates and NTLM maybe?

But then again, when I access through our internal URL, it just goes over port 80, so no certs there. I don't know. Just hopefully giving some helpful details!

Huan, can you take a look at the crash dumps? This might be a dup but I can't seem to find the other bug report.

The early results from 458.1 crash reports already show a crash spike on this. Could be due to this change on HttpAuthHandlerNegotiate? http://src.chromium.org/viewvc/chrome?view=rev&revision=51387

call stack:

01b3f944 024301b1 chrome_1c30000!net::SingleRequestHostResolver::Resolve+0xa [c:\b\slave\chrome-official\build\src\net\base\host_resolver.cc @ 39]
01b3fa18 024300e3 chrome_1c30000!net::HttpAuthHandlerNegotiate::DoResolveCanonicalName+0xb3 [c:\b\slave\chrome-official\build\src\net\http\http_auth_handler_negotiate.cc @ 190]
01b3fa24 0242fec1 chrome_1c30000!net::HttpAuthHandlerNegotiate::DoLoop+0x87 [c:\b\slave\chrome-official\build\src\net\http\http_auth_handler_negotiate.cc @ 174]
01b3fa2c 0243e91c chrome_1c30000!net::HttpAuthHandlerNegotiate::GenerateAuthTokenImpl+0x68 [c:\b\slave\chrome-official\build\src\net\http\http_auth_handler_negotiate.cc @ 75]
01b3fa64 02435c0b chrome_1c30000!net::HttpAuthHandler::GenerateAuthToken+0x7b [c:\b\slave\chrome-official\build\src\net\http\http_auth_handler.cc @ 95]
01b3fa80 02402e07 chrome_1c30000!net::HttpAuthController::MaybeGenerateAuthToken+0x50 [c:\b\slave\chrome-official\build\src\net\http\http_auth_controller.cc @ 79]
01b3faa4 02402982 chrome_1c30000!net::HttpNetworkTransaction::DoLoop+0xad [c:\b\slave\chrome-official\build\src\net\http\http_network_transaction.cc @ 603]
01b3fab4 0241f2af chrome_1c30000!net::HttpNetworkTransaction::RestartWithAuth+0x33 [c:\b\slave\chrome-official\build\src\net\http\http_network_transaction.cc @ 401]
01b3fb1c 02455c64 chrome_1c30000!net::HttpCache::Transaction::RestartWithAuth+0x67 [c:\b\slave\chrome-official\build\src\net\http\http_cache_transaction.cc @ 240]
01b3fb40 024557f3 chrome_1c30000!URLRequestHttpJob::StartTransaction+0x2f [c:\b\slave\chrome-official\build\src\net\url_request\url_request_http_job.cc @ 621]
01b3fb8c 02455f6e chrome_1c30000!URLRequestHttpJob::OnCanGetCookiesCompleted+0xff [c:\b\slave\chrome-official\build\src\net\url_request\url_request_http_job.cc @ 460]
01b3fba8 02455509 chrome_1c30000!URLRequestHttpJob::AddCookieHeaderAndStart+0x6d [c:\b\slave\chrome-official\build\src\net\url_request\url_request_http_job.cc @ 739]
01b3fbc4 02455c08 chrome_1c30000!URLRequestHttpJob::RestartTransactionWithAuth+0x69 [c:\b\slave\chrome-official\build\src\net\url_request\url_request_http_job.cc @ 345]
01b3fc7c 02455fbd chrome_1c30000!URLRequestHttpJob::NotifyHeadersComplete+0x121 [c:\b\slave\chrome-official\build\src\net\url_request\url_request_http_job.cc @ 599]
01b3fc9c 0245598c chrome_1c30000!URLRequestHttpJob::SaveNextCookie+0x4b [c:\b\slave\chrome-official\build\src\net\url_request\url_request_http_job.cc @ 762]
01b3fcc0 0242dcd0 chrome_1c30000!URLRequestHttpJob::OnStartCompleted+0x78 [c:\b\slave\chrome-official\build\src\net\url_request\url_request_http_job.cc @ 515]
01b3fccc 0241f842 chrome_1c30000!CallbackImpl<net::SpdySession,void (__thiscall net::SpdySession::*)(int),Tuple1<int> >::RunWithParams+0x14 [c:\b\slave\chrome-official\build\src\base\callback.h @ 118]
01b3fcec 01e61179 chrome_1c30000!net::HttpCache::Transaction::DoLoop+0x2f4 [c:\b\slave\chrome-official\build\src\net\http\http_cache_transaction.cc @ 545]
01b3fcf4 02402d55 chrome_1c30000!CallbackImpl<TipsHandler,void (__thiscall TipsHandler::*)(Value const *),Tuple1<Value const *> >::RunWithParams+0xe [c:\b\slave\chrome-official\build\src\base\callback.h @ 119]
01b3fd04 01e61179 chrome_1c30000!net::HttpNetworkTransaction::OnIOComplete+0x26 [c:\b\slave\chrome-official\build\src\net\http\http_network_transaction.cc @ 575]

cbentzel: could you take a look at this crash?

eroman and I will see if we can come up with a fix quickly.  If we can't,
we plan to revert r51387 at 6:00 PM US Pacific Time tonight.

Revert is fine - I apologize for not doing it sooner. I'll debug and try to
fix over the wekend

The problem is we never call:
  HttpAuthHandlerNegotiate::Factory::set_host_resolver()

So resolver ends up being NULL.

This is a simple ommission in

  IOThread::CreateDefaultAuthHandlerFactory(HostResolver* resolver)

It has the |resolver| parameter and everything, it just never sets it :)


I can prepare a quick fix for this if you decide not to revert.

Oh jeez. Fix is fine. Wow that was bad.

Comment #9 on  issue 48690  by eroman@chromium.org: crashes when trying access
some intranet (NTLM) websites.


https://code.google.com/p/chromium/issues/detail?id=48690
The problem is we never call:
 HttpAuthHandlerNegotiate::Factory::set_host_resolver()

So resolver ends up being NULL.

This is a simple ommission in

 IOThread::CreateDefaultAuthHandlerFactory(HostResolver* resolver)

It has the |resolver| parameter and everything, it just never sets it :)


I can prepare a quick fix for this if you decide not to revert.

For people impacted by this, you can specify --disable-auth-negotiate-cname-lookup on the command line to avoid the crash. However, authentication may not work correctly in that case depending on how your local environment is configured. 

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=52025 

------------------------------------------------------------------------
r52025 | eroman@chromium.org | 2010-07-09 17:27:00 -0700 (Fri, 09 Jul 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/io_thread.cc?r1=52025&r2=52024

Fix a crash when using negotiate HTTP auth.

BUG=48690

Review URL: http://codereview.chromium.org/2896007
------------------------------------------------------------------------

cbentzel: I verified eroman's fix.

However, we still hit a DCHECK failure in debug build when
automatic logon isn't being used.  The DCHECK fails after
I enter the username and password into the HTTP auth dialog.

void URLRequestHttpJob::NotifyHeadersComplete() {
  ...
  // The HTTP transaction may be restarted several times for the purposes
  // of sending authorization information. Each time it restarts, we get
  // notified of the headers completion so that we can update the cookie store.
  if (transaction_->IsReadyToRestartForAuth()) {
    DCHECK(!response_info_->auth_challenge.get());  <=== FAILED
    RestartTransactionWithAuth(std::wstring(), std::wstring());
    return;
  }

response_info_->auth_challenge.get() is not NULL.  If I continue beyond
the DCHECK failure, things work.

committed in r52025.

We can track the DCHECK in comment #13 in a separate bug.

That DCHECK was added by eroman a long time ago.  svn blame says:

 12635 ericroman@google.com   // The HTTP transaction may be restarted several times for the purposes
 12635 ericroman@google.com   // of sending authorization information. Each time it restarts, we get
 12635 ericroman@google.com   // notified of the headers completion so that we can update the cookie store.
 12635 ericroman@google.com   if (transaction_->IsReadyToRestartForAuth()) {
 12635 ericroman@google.com     DCHECK(!response_info_->auth_challenge.get());
 12635 ericroman@google.com     RestartTransactionWithAuth(std::wstring(), std::wstring());
 12635 ericroman@google.com     return;
 12635 ericroman@google.com   }
 12635 ericroman@google.com 

The SVN commit comment is:

r12635 | ericroman@google.com | 2009-03-26 21:00:22 -0700 (Thu, 26 Mar 2009) | 25 lines

Respect cookies set in a 401 responses when restarting the http transaction.

There are two parts to this change:
(1) rebuild the request cookies before each transaction restart for
    authentication
(2) notify the URLRequestHttpJob of header completion before *each*
    transaction restart for authentication

By "each transaction" I mean the automatic restarts that don't require
user input, such as:
 - replying to the first step of NTLM
 - selecting identity embedded in URL
 - selecting identity in auth-cache

Needing to notify URLRequestHttpJob for these intermediate restarts is
a consequence of cookie store management being done outside of
HttpNetworkTransaction.

After updating the cookie store, URLRequestHttpJob now tests
|HttpTransaction::IsReadyToRestartForAuth()| to check whether the
notification was informational or an identity is actually needed.

R=wtc
BUG=6450
Review URL: http://codereview.chromium.org/51004

I'll move the DCHECK into another bug. It was triggered by the HttpAuthController work which vandebo recently introduced. I'll send out a fix tomorrow morning for it.

DCHECK bug: https://code.google.com/p/chromium/issues/detail?id=48752

 Issue 48377  has been merged into this issue.

 Issue 48723  has been merged into this issue.

 Issue 48675  has been merged into this issue.

 Issue 48829  has been merged into this issue.

 Issue 48845  has been merged into this issue.

 Issue 48838  has been merged into this issue.

 Issue 48822  has been merged into this issue.

 Issue 48816  has been merged into this issue.

 Issue 48785  has been merged into this issue.

 Issue 48853  has been merged into this issue.

 Issue 48587  has been merged into this issue.

To all those who read this before the fix goes live, try adding this command line flag:
--disable-auth-negotiate-cname-lookup

Command line flag workaround works 

 Issue 48899  has been merged into this issue.

after add --disable-auth-negotiate-cname-lookup it works.

Same for me, this flag solves my problem.

Still an issue in 6.0.458.1. --disable-auth-negotiate-cname-lookup also prevents the instant-crash.

Some Google keyphrases (took me a while to find this):
Chrome instant crash
Chrome crashes straight away
Chrome ISA crash
Chrome proxy crash

6.0.458.1 was created before the bug fix. The next dev release should not have this problem.

 Issue 48929  has been merged into this issue.

 Issue 48928  has been merged into this issue.

 Issue 49052  has been merged into this issue.

 Issue 48966  has been merged into this issue.

 Issue 49065  has been merged into this issue.

 Issue 49135  has been merged into this issue.

(No comment was entered for this change.)

I can confirm that release 6.0.466.0 fixes this problem. I no longer need to use the --disable-auth-negotiate-cname-lookup start-up flag.

Also confirmed that 6.0.466.0 dev works fine now.  Thanks!

Thank you for the 6.0.466.0 fix confirmations, but no more are necessary.

Chrome Version       : 6.0.458.1
URLs (if applicable) : <internal>
<b>Other browsers tested:</b>
<b>Add OK or FAIL after other browsers where you have tested this issue:</b>
<b>Safari 4:</b>
  Firefox 3.x: OK
         IE 7: OK
         IE 8: OK

<b>What steps will reproduce the problem?</b>
1. Attempt to one of several intranet URLs (but not all)
2. Watch Chrome crash hard
<b>3.</b>

<b>What is the expected result?</b>

Not crashing, like it did on the previous DEV version.

<b>What happens instead?</b>

Crashes and goes away.

As a side effect, I can't actually submit this bug from this version of Chrome...I get a &quot;client has issued a malformed or illegal request&quot;. Submitting bug from FF.

<b>Please provide any additional information below. Attach a screenshot if</b>
<b>possible.</b>

Here's the two entries in the event logs:

Faulting application name: chrome.exe, version: 0.0.0.0, time stamp: 0x4c34f0ac
Faulting module name: chrome.dll, version: 6.0.458.1, time stamp: 0x4c34f079
Exception code: 0xc0000005
Fault offset: 0x007c62b8
Faulting process id: 0x21f0
Faulting application start time: 0x01cb1f8fa102531e
Faulting application path: C:\Users\epollock\AppData\Local\Google\Chrome\Application\chrome.exe
Faulting module path: C:\Users\epollock\AppData\Local\Google\Chrome\Application\6.0.458.1\chrome.dll
Report Id: a8c1b7ab-8b83-11df-b0ca-0026b986bd12

Faulting application name: chrome.exe, version: 0.0.0.0, time stamp: 0x4c34f0ac
Faulting module name: chrome.dll, version: 6.0.458.1, time stamp: 0x4c34f079
Exception code: 0xc0000005
Fault offset: 0x007c62b8
Faulting process id: 0x21f0
Faulting application start time: 0x01cb1f8fa102531e
Faulting application path: C:\Users\epollock\AppData\Local\Google\Chrome\Application\chrome.exe
Faulting module path: C:\Users\epollock\AppData\Local\Google\Chrome\Application\6.0.458.1\chrome.dll
Report Id: a8c1b7ab-8b83-11df-b0ca-0026b986bd12

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)