| 一. 启动: 1.WinMain:在chrome exe工程的chrome_exe_main.cc中， MainDllLoader* loader = MakeMainDllLoader(); int rc = loader->Launch(instance, &sandbox_info);主要是加载chrome.dll文件. MainDllLoader::Launch的实现在client_util.cc中,动态获取chrome.dll中的入口函数“ChromeMain”的地址然后调用进入. 2. ChromeMain的实现在chrome_main.cc->content_main.cc->content_main_runner.cc中(src\content\app\content_main_runner.cc)： if (process_type == switches::kRendererProcess) { rv = RendererMain(main_params); } else if (process_type == switches::kExtensionProcess) { // An extension process is just a renderer process. We use a different // command line argument to differentiate crash reports.扩展进程入口 rv = RendererMain(main_params); } else if (process_type == switches::kPluginProcess) { rv = PluginMain(main_params); } else if (process_type == switches::kUtilityProcess) { rv = UtilityMain(main_params); } else if (process_type.empty()) { ScopedOleInitializer ole_initializer; rv = BrowserMain(main_params); //主进程，启动进这里 } else 3.Browser主进程入口在browser_main.cc中， BrowserInit位置http://src.chromium.org/svn/branches/official/build_164.0/src/chrome/browser/browser_init.h a.生成UI类型的消息循环对象main_message_loop b.生成browser进程对象browser_process，并初始化（启动）文件、数据库、io等辅助线程。 c.调用BrowserInit::ProcessCommandLine->BrowserInit::LaunchBrowserImpl->BrowserInit::Launch->{ if (!OpenApplicationURL(profile)) { std::vector<GURL> urls_to_open = GetURLsFromCommandLine(profile_); if (!OpenStartupURLs(process_startup, urls_to_open)) { OpenURLsInBrowser(browser, process_startup, urls_to_open)->Browser::AddTabWithURL,browser-> window ()->Show (); } } 启动浏览器主UI界面，该句执行后，浏览器窗口就显示出来了。 d.调用RunUIMessageLoop进入浏览器UI主线程消息循环，后续工作完全基于消息驱动。
在c步中，浏览器窗口启动过程,在/chrome/browser/ui/browser_init.cc中, browser_init.cc文件中的BrowserInit::LaunchWithProfile::OpenURLsInBrowser()，整理如下： 该函数会创建一个Browser对象，每一个浏览器窗口都对应一个Browser对象。然后调用browser对象的AddTabWithURL 方法来打开相应的URL，我们的主页地址也将在AddTabWithURL中被打开。最后调用browser->window()->Show(), 显示浏览器UI窗口，对应的url页面也将被显示。 e.在OpenURLsInBrowser中， TabContents* contents = CreateTabContentsForURL(url_to_load, referrer, profile_, transition, false, instance); tabstrip_model_.AddTabContents(contents, -1, transition, foreground); 在CreateTabContentsForURL中 TabContents* contents = TabContents::CreateWithType(type, profile, instance); contents->SetupController(profile); if (!defer_load) { // Load the initial URL before adding the new tab contents to the tab strip // so that the tab contents has navigation state. contents->controller()->LoadURL(url, referrer, transition); } f.TabContents(表示一个标签)直接和render交互，http://www.douban.com/note/32671779/ 在LoadURL(navigation_controller.cc)中 NavigationEntry* entry = CreateNavigationEntry(url, referrer, transition); //entry是当前tab的导航历史 LoadEntry(entry); 在LoadEntry中 DiscardNonCommittedEntriesInternal(); pending_entry_ = entry; NotificationService::current()->Notify( NotificationType::NAV_ENTRY_PENDING, Source<NavigationController>(this), NotificationService::NoDetails() ); NavigateToPendingEntry(false)； g.在WebContents中实现了NavigateToPendingEntry函数，后面新建render Host进程，见http://blog.csdn.net/zero_lee/article/details/7870243 h.delegate_::CreateRenderViewForRenderManager或者说是WebContents类的这个函数（因为WebContents是一种RenderViewHostManager::delegate）会调用RenderViewHost::CreateRenderView函数，创建一个Render进程，如果还不存在的话。 4.Renderer进程启动: 作为多进程架构，所谓Renderer进程就是内核的渲染进程，每个页面的显示都有Renderer进程中相应的内核对象与之对应。 Renderer进程主要包含了Webkit和V8两大内核对象。 Renderer进程的启动过程是随着URL的打开而启动，即browser->AddTabWithURL调用会触发Renderer进程的启动，具体在browser_render_process_host.cc中的Init方法. browser_render_process_host.cc文件是理解体系结构很重要的一个文件，其中的Init方法是关键。可以在该方法中 设置断点，通过查看调用栈可以了解详细的调用路径。在Init中，先构造一个资源消息过滤器(ResourceMessageFilter) 然后构造和Renderer进程通信的IPC通道，并将资源消息过滤器安装在该通道上。最后通过构造一个ChildProcessLauncher 对象来启动Renderer进程，注意ChildProcessLauncher构造函数传递了执行文件路径，命令行等参数。 这里的关键是ChromeThread::PostTask()的调用。该函数是chrome中线程调度体系的一个重要助手函数。当一个线程需要向另外一个线程投递一个任务时（在另外一个线程上运行指定的代码）调用该函数很方便，第一个参数是目标线程的标识符（chrome的每种线程都有对应的标识符，通过标识符就可以获取到线程对象）。第三个参数是需要在目标线程上运行的代码。chrome提供了很多灵活的模板方法（可以参考base项目中的task.h实现）来构造第三个参数，第三个参数即可以是一个独立的函数入口，又可以是某个类对象的公有方法，且该方法可以有任意的参数数目和数据类型。 在这里，主UI线程把启动Render进程的任务投递给独立的“进程启动者线程”（PROCESS_LAUNCHER）来完成，具体的代码是调用Context::LaunchInternal()方法： 5.Render进程入口: 在Renderer工程的render_view.cc这个关键文件中设定断点来查看调用栈。注意：为了及早跟踪必须尽早附加到启动后的Render进程，所以最早的时机是执行了上面LaunchInternal函数中的语句handle = sandbox::StartProcessWithAccess(cmd_line, exposed_dir); 该语句执行后Render进程就生成了，此时通过vs2008 ”Tools“菜单中的“Attach to Process”来附加到Render进程(chrome.exe)。 通过调用栈可以看到该函数的调用路径，从调用路径中可以看出该初始化过程是由一个IPC消息触发，消息通过IPC通道最终被分派到void ChildThread::OnMessageReceived(…)，通过消息映射，该消息ViewMsg_New由相应的函数来处理，并最终调用到RenderView::Init完成内核初始化。在RenderView::Init中，webview()->initializeMainFrame(this)此句完成了webkit内核的初始化。 以后的过程就是主进程和Renderer进程通过IPC通道进行消息交互的协作过程。 ViewMsg_New消息是浏览器主进程在打开新页面的时候发送给Renderer进程的控制消息，其目的是打开一个对应的RenderView对象完成内核初始化，在主进程中与之对应的通信对象是RenderViewHost。 6.打开url堆栈，部分解析过程http://blog.csdn.net/dlmu2001/article/details/6164873： bu DocumentLoader::startLoadingMainResource 4:006> bl 0 e 01cd2758 0001 (0001) 4:**** chrome_child!WebCore::HTMLFrameElementBase::openURL 1 e 0199c8da 0001 (0001) 4:**** chrome_child!WebKit::WebFrameImpl::create 2 e 020a5b98 0001 (0001) 4:**** chrome_child!WebCore::EmptyFrameLoaderClient::createDocumentLoader 3 e 0199cb6d 0001 (0001) 4:**** chrome_child!WebCore::Frame::create 4 e 02b577e9 0001 (0001) 4:**** chrome_child!ViewHostMsg_OpenURL_Params::ViewHostMsg_OpenURL_Params Breakpoint 1 hit eax=0026f20c ebx=017a7b00 ecx=01723900 edx=03036be0 esi=016ebc00 edi=01723900 eip=0199c8da esp=0026f1f0 ebp=0026f204 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202 chrome_child!WebKit::WebFrameImpl::create: 0199c8da 55 push ebp 4:006> kv 100 ChildEBP RetAddr Args to Child 0026f1ec 0199c8a5 0026f20c 017a7168 03039160 chrome_child!WebKit::WebFrameImpl::create (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\third_party\webkit\source\web\webframeimpl.cpp @ 2065] 0026f204 0198bd25 017a7168 00000001 01724734 chrome_child!WebKit::WebViewImpl::initializeMainFrame+0x13 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\third_party\webkit\source\web\webviewimpl.cpp @ 321] 0026f250 0198a799 0026f260 016c2b00 fffffffe chrome_child!content::RenderViewImpl::Initialize+0x290 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\content\renderer\render_view_impl.cc @ 909] 0026f29c 0198a713 fffffffe 0026f2fc 0026f3b4 chrome_child!content::RenderViewImpl::Create+0x7f (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\content\renderer\render_view_impl.cc @ 1083] 0026f2e4 01988cd4 0026f2fc 01724734 016c2b04 chrome_child!content::RenderThreadImpl::OnCreateNewView+0x70 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\content\renderer\render_thread_impl.cc @ 1126] 0026f5b0 0192d0c3 01724734 016c2b00 016c2b00 chrome_child!ViewMsg_New::Dispatch<content::RenderThreadImpl,content::RenderThreadImpl,void (__thiscall content::RenderThreadImpl::*)(ViewMsg_New_Params const &)>+0x4a (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\content\common\view_messages.h @ 814] 0026f650 018e69d6 01724734 016e8e10 034d39ff chrome_child!content::RenderThreadImpl::OnControlMessageReceived+0x21f (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\content\renderer\render_thread_impl.cc @ 1097] 0026f6bc 018e682c 01724734 0026f798 016c0c98 chrome_child!content::ChildThread::OnMessageReceived+0x196 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\content\child\child_thread.cc @ 350] 0026f6ec 018e6796 01724734 016c0c98 0026f770 chrome_child!IPC::ChannelProxy::Context::OnDispatchMessage+0x93 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\ipc\ipc_channel_proxy.cc @ 270] 0026f6fc 018e5acf 01724720 0026fb24 01724724 chrome_child!base::internal::Invoker<2,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall content::P2PHostAddressRequest::*)(std::vector<unsigned char,std::allocator<unsigned char> > const &)>,void __cdecl(content::P2PHostAddressRequest *,std::vector<unsigned char,std::allocator<unsigned char> > const &),void __cdecl(content::P2PHostAddressRequest *,std::vector<unsigned char,std::allocator<unsigned char> >)>,void __cdecl(content::P2PHostAddressRequest *,std::vector<unsigned char,std::allocator<unsigned char> > const &)>::Run+0x16 (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\base\bind_internal.h @ 1253] 0026f770 018e580a 0026fb24 0026f798 016cf480 chrome_child!base::MessageLoop::RunTask+0x223 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\base\message_loop\message_loop.cc @ 493] 0026f8c0 018e8761 0026fb24 0026f92c 00000000 chrome_child!base::MessageLoop::DoWork+0x301 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\base\message_loop\message_loop.cc @ 618] 0026f8e4 01900782 0026f910 018e5455 0026fb24 chrome_child!base::MessagePumpDefault::Run+0xca (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\base\message_loop\message_pump_default.cc @ 33] 0026f948 019000b5 016d0d50 00000005 00000000 chrome_child!base::debug::TraceLog::AddTraceEventEtw+0x28 (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\base\debug\trace_event_impl.cc @ 1627] 0026fc60 018dce7f 0026fc94 016d0d20 00000000 chrome_child!content::RendererMain+0x398 (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\content\renderer\renderer_main.cc @ 253] 0026fc74 018dcde3 0026fca4 0026fc94 0026fd08 chrome_child!content::RunNamedProcessTypeMain+0x7b (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\content\app\content_main_runner.cc @ 458] 0026fce0 018cb04f 010f1c80 010f5a88 0026fd28 chrome_child!content::ContentMainRunnerImpl::Run+0x85 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\content\app\content_main_runner.cc @ 777] 0026fcf0 018caa94 011e0000 0026fdb8 0026fd08 chrome_child!content::ContentMain+0x29 (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\content\app\content_main.cc @ 35] 0026fd28 01208907 011e0000 0026fdb8 0026fdc0 chrome_child!ChromeMain+0x2b (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\chrome\app\chrome_main.cc @ 34] 0026fda0 0120ae38 011e0000 0026fdb8 00000000 chrome!MainDllLoader::Launch+0xf5 (FPO: [Non-Fpo]) (CONV: thiscall) [c:\b\build\slave\win\build\src\chrome\app\client_util.cc @ 298] 0026fdc4 0120aeb5 011e0000 00000000 007837a8 chrome!`anonymous namespace'::RunChrome+0x5e (FPO: [Non-Fpo]) (CONV: cdecl) [c:\b\build\slave\win\build\src\chrome\app\chrome_exe_main_win.cc @ 49] 0026fe0c 01229ef3 011e0000 00000000 00771e9c chrome!wWinMain+0x62 (FPO: [Non-Fpo]) (CONV: stdcall) [c:\b\build\slave\win\build\src\chrome\app\chrome_exe_main_win.cc @ 115] 0026fe9c 76c6ed5c 7ffdc000 0026fee8 76e137eb chrome!__tmainCRTStartup+0x11a (FPO: [Non-Fpo]) (CONV: cdecl) [f:\dd\vctools\crt_bld\self_x86\crt\src\crt0.c @ 275] 0026fea8 76e137eb 7ffdc000 76998269 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo]) 0026fee8 76e137be 01229f46 7ffdc000 ffffffff ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo]) 0026ff00 00000000 01229f46 7ffdc000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo]) 7.其中 WebFrameImpl是webframe的实现类，WebFrameImpl架起了chromium的render process和webkit的桥梁，感兴趣的可以阅读源码接口；关于FrameLoader，见http://blog.csdn.net/shunzi__1984/article/details/6262526 http://www.cnblogs.com/xyz2abc/archive/2012/05/08/2489895.html 在FrameLoader的load函数中主要做了以下事情： a、初始化相应的Request，比如FrameLoadRequest和ResourceRequest;以及相应的FrameLoadType; b、调用loadWithNavigationAction函数---> loadWithNavigationAction函数的功能： a、通过m_client(FrameLoadClientImpl)的createDocumentLoader函数得到一个DocumentLoader，实际上是DocumentLoader的后代WebDataSourceImpl，它重写了部分DocumentLoader的接口功能，这样就把webkit的网络加载请求可以转化为对chromium的请求，我个人的猜测，具体要看了代码才知道 b、设置第一步得到的DocumentLoader的一些属性，并把该Loader赋给m_policyDocumentLoader，并做了相关的清除工作，见FrameLoader的setPolicyDocumentLoader函数 c、呼叫checkNavigationPolicyAndContinueLoad函数---> checkNavigationPolicyAndContinueLoad的功能： a、通过一系列的检查，看能否继续进行加载 b、如果能加载就呼叫setProvisionalDocumentLoader，把m_policyDocumentLoader赋给m_provisionalDocumentLoader，进入到FrameStateProvisional状态 c、呼叫prepareForLoadStart，在这个函数里呼叫RenderViewImpl的dispatchDidStartProvisionalLoad函数，一直到WebContentImpl的DidStartProvisionalLoadForFrame函数 d、加载前的相关准备工作，呼叫m_provisionalDocumentLoader->startLoadingMainResource开始加载，这里呼叫的是DocumentLoader的startLoadingMainResource函数，虽然是通过WebDataSourceImpl的对象进行呼叫的---> DocumentLoader::startLoadingMainResource，正式开始加载(在src\third_party\WebKit\Source\core\loader\DocumentLoader.cpp中) a、呼叫willSendRequest函数，处理redirection等情况，处理空网页情况 b、发送请求前的准备工作 c、调用CachedResourceLoader的requestMainResource函数，发送加载网页ResourceRequest请求给浏览器(browser)； ResourceRequest请求是一个类，格式在src\third_party\WebKit\Source\core\platform\network\ResourceRequst.h中，包括对html头的设置方法，Kurl，请求显示类型。其中，kurl在src\third_party\WebKit\Source\weborigin\krul.h定义， 包含url字串。
二.加载及解析，渲染URL过程. 1.LoadUrl回调用到FrameLoader的load，在FrameLoader::load中会创建DocumentLoader，DocumentLoader会被FrameLoader维护。 DocumentLoader中有成员mutable DocumentWriter m_writer. DocumentWriter该类位于WebCore/loader目录下.DocumentWriter相当于 loader与parser的桥梁。这里先看下loader与parser之间的关联的流程。进一步的调用后会调用到DocumentLoader::commitData。 在DocumentLoader::commitData中执行了二个使用DocumentWriter的操作。 a.对DocumentWriter设置编码，DocumentWriter::setEncoding b.把收到的数据转交给DocumentWriter，DocumentWriter::addData。 结束接收数据时调用了DocumentWriter::end函数。 2.与dom关联的起源 在src\third_party\WebKit\Source\core\loader\DocumentWriter.cpp中. DocumentWriter::setEncoding.该函数会通过成员Frame找到FrameLoader，然后调用FrameLoader::willSetEcoding。这个函数会进一步调用FrameLoader::receivedFirstData. 调用了DocumentWriter::begin之后，该函数会会通过DocumentWriter::createDocument创建一个Document。 3.开始dom Document在src\third_party\WebKit\Source\core\dom\Document.pp中,创建Document的函数是DOMImplementation::createDocument.它会根据参数传入的MimeType来创建具体的Document子类。这些具体的子类绝大多数都是在WebCore/html目录下定义的. 在DocumentWrite::begin中，创建完Document后，会把这个Document设置给DocumentWrite的成员Frame中。通过函数Frame::setDocument，然后调用调用了Document::attach。Node与RenderObject关联和接关联就是通过attach和detach函数。 Document的另一个祖先类ContainerNode，该类也实现了attach虚函数，ContainerNode:: attach的实现就是调用其每个子Node的attach，最后调用其基类的Node::attach。因为ContainerNode是个容器，所以ContainerNode有一堆子Node，因为有子Node，所以子Node也要调用attach。Document是个特殊的Node，它是整个DOM树的根，所以它对应的RenderObject也要特殊，他对应的是RenderView，他是Render树的根。Document::attach中创建了RenderView，并把它设置给Document，主要工作就是 创建并设置RenderView。数据都是从ResourceLoader(MainResourceLoader)中传到DocumentLoader 再进一步传到DocumentWriter，最后传给Document 的。 4.创建dom解析器。 执行了FrameLoader::didBeginDocument之后，会调用Document::implicitOpen，该函数中创建parser. HTMLDocumentParser在WebCore/html/parser/目录下,构造函数中HTMLTokenizer，HTMLTreeBuilder都会被创建。 到现在ResourceLoader(MainResourceLoader)->传递回调->DocumentLoader->构造时一并创建->DocumentWriter->setEncoding-> begin->创建HTMLDocument(与RenderView)-> implicitOpen->创建HTMLDocumentParser。 setEncoding只有在第一次接收到数据时才会调用begin后面的操作，每次接收数据setEncoding都会被调用，但是后续的数据接收并不会每次都创建一遍HTMLDocument了。 5.开始即完成解析. 进入DocumentParser的解析,DocumentWriter::addData,把参数传进来的数据转交给DocumentParser::appendBytes。完成解析时， DocumentWriter::end先执行一个DocumentParser::appendBytes(0, 0, true)这个true表示flush。即通知解析器把Buffer存的数据都解析完。 6.具体词法及句法解码过程。 http://blog.csdn.net/hxwwf/article/details/7429746 7.渲染过程 http://blog.csdn.net/hxwwf/article/details/7646359 8.extension扩展进程 chrome在启动或者安装扩展时，调用src\src\base\json\JSONFileValueSerializer.cc解析manifest.json文件，解析完后循环等待接收tab发来的消息。 当前tab可以在document_start，document_end或者document_idle时候加载当前的extension的content js脚本内容。
9.npapi插件进程 在src\content\plugin\plugin_main.cc中，PluginMain函数在插件进程被启动时调用,判断是否是有窗口的插件，新建PluginThread线程，调用PatchNPNFunctions函数 。然后加载插件dll文件，调用插件的NP_Initialize函数。然后进入消息循环接收task调用，堆栈如下： > sample.dll!CSample::HasMethod(void * name=0x03f5c9e0) Line 78 C++ sample.dll!CSample::_HasMethod(NPObject * npobj=0x05d51404, void * name=0x03f5c9e0) Line 33 + 0x43 bytes C++ chrome_child.dll!content::NPObjectStub::OnHasMethod(const content::NPIdentifier_Param & name={...}, bool * result=0x0028ef38) Line 127 + 0xa bytes C++ chrome_child.dll!IPC::SyncMessageSchema<Tuple1<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,Tuple1<bool &> >::DispatchWithSendParams<ppapi::proxy::PluginDispatcher,ppapi::proxy::PluginDispatcher,void (__thiscall ppapi::proxy::PluginDispatcher::*)(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,bool *)>(bool ok=true, const Tuple1<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > & send_params={...}, const IPC::Message * msg=0x03f5ca40, ppapi::proxy::PluginDispatcher * obj=0x03f31ea0, ppapi::proxy::PluginDispatcher * sender=0x03f31ea0, void (const std::basic_string<char,std::char_traits<char>,std::allocator<char> > &, bool *)* func=0x03067d24) Line 822 C++ chrome_child.dll!NPObjectMsg_RemoveProperty::Dispatch<content::NPObjectStub,content::NPObjectStub,void (__thiscall content::NPObjectStub::*)(content::NPIdentifier_Param const &,bool *)>(const IPC::Message * msg=0x03f5ca40, content::NPObjectStub * obj=0x03f31ea0, content::NPObjectStub * sender=0x03f31ea0, void (const content::NPIdentifier_Param &, bool *)* func=0x03067d24) Line 359 + 0x38 bytes C++ chrome_child.dll!content::NPObjectStub::OnMessageReceived(const IPC::Message & msg={...}) Line 93 + 0x37 bytes C++ chrome_child.dll!content::MessageRouter::RouteMessage(const IPC::Message & msg={...}) Line 50 C++ chrome_child.dll!content::NPChannelBase::OnMessageReceived(const IPC::Message & message={...}) Line 182 + 0xb bytes C++ chrome_child.dll!content::PluginChannel::OnMessageReceived(const IPC::Message & msg={...}) Line 189 + 0x9 bytes C++ chrome_child.dll!IPC::ChannelProxy::Context::OnDispatchMessage(const IPC::Message & message={...}) Line 270 C++ chrome_child.dll!IPC::SyncChannel::ReceivedSyncMsgQueue::DispatchMessages(IPC::SyncChannel::SyncContext * dispatching_context=0x03f56e10) Line 126 C++ chrome_child.dll!IPC::SyncChannel::SyncContext::DispatchMessages() Line 298 C++ chrome_child.dll!IPC::SyncChannel::ReceivedSyncMsgQueue::DispatchMessagesTask(IPC::SyncChannel::SyncContext * context=0x03f56e10) Line 93 + 0x8 bytes C++ chrome_child.dll!base::internal::Invoker<2,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall `anonymous namespace'::HeapStatisticsCollector::*)(int)>,void __cdecl(`anonymous namespace'::HeapStatisticsCollector *,int),void __cdecl(base::internal::UnretainedWrapper<`anonymous namespace'::HeapStatisticsCollector>,int)>,void __cdecl(`anonymous namespace'::HeapStatisticsCollector *,int)>::Run(base::internal::BindStateBase * base=0x03f5cf40) Line 1254 C++ chrome_child.dll!base::MessageLoop::RunTask(const base::PendingTask & pending_task={...}) Line 493 C++ chrome_child.dll!base::MessageLoop::DoWork() Line 618 C++ chrome_child.dll!base::MessagePumpForUI::DoRunLoop() Line 243 + 0x9 bytes C++ chrome_child.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate=0x0028f494) Line 48 + 0x3e bytes C++ chrome_child.dll!base::MessageLoop::RunInternal() Line 442 C++ chrome_child.dll!base::MessageLoop::RunInternalInSEHFrame() Line 420 + 0x8 bytes C++ chrome_child.dll!base::RunLoop::Run() Line 47 + 0x11 bytes C++ chrome_child.dll!base::MessageLoop::Run() Line 312 C++ chrome_child.dll!content::PluginMain(const content::MainFunctionParams & parameters={...}) Line 82 C++ chrome_child.dll!content::RunNamedProcessTypeMain(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & process_type="plugin", const content::MainFunctionParams & main_function_params={...}, content::ContentMainDelegate * delegate=0x0028f670) Line 458 + 0xa bytes C++ chrome_child.dll!content::ContentMainRunnerImpl::Run() Line 777 + 0x1c bytes C++ chrome_child.dll!content::ContentMain(HINSTANCE__ * instance=0x00910000, sandbox::SandboxInterfaceInfo * sandbox_info=0x0028f720, content::ContentMainDelegate * delegate=0x0028f670) Line 35 + 0x3 bytes C++ chrome_child.dll!ChromeMain(HINSTANCE__ * instance=0x00910000, sandbox::SandboxInterfaceInfo * sandbox_info=0x0028f720) Line 34 C++ chrome.exe!MainDllLoader::Launch(HINSTANCE__ * instance=0x00910000, sandbox::SandboxInterfaceInfo * sbox_info=0x0028f720) Line 298 C++ chrome.exe!`anonymous namespace'::RunChrome(HINSTANCE__ * instance=0x00910000) Line 49 C++ chrome.exe!wWinMain(HINSTANCE__ * instance=0x00910000, HINSTANCE__ * prev=0x00000000, wchar_t * __formal=0x00481e4c, wchar_t * __formal=0x00481e4c) Line 115 + 0x8 bytes C++ chrome.exe!__tmainCRTStartup() Line 275 + 0x1c bytes C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
|
--写于2013-12-11
2514
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
