ไม่พบกระบวนการ w3wp

ฉันใช้ Visual Studio 2010 เพื่อดีบักโครงการ asp.net MVC ในเครื่องท้องถิ่นของฉัน ขั้นตอนมีดังนี้

คลิก Debug และพยายามแนบกระบวนการ "w3wp.exe" อย่างไรก็ตามมันไม่ได้อยู่ในรายการ

ฉันแน่ใจว่ามีการคลิก "แสดงกระบวนการในทุกเซสชัน"

w3wp.exe จะไม่แสดงในกระบวนการทำงาน 'เว้นแต่จะมีอินสแตนซ์ของเว็บแอปพลิเคชันที่ทำงานอยู่

พยายามเข้าถึงหน้าเว็บของคุณก่อนเมื่อแสดงเป็นครั้งแรกให้ลองแนบโปรแกรมแก้ไขข้อบกพร่องของคุณ กระบวนการนี้ควรปรากฏขึ้น

คุณต้องคลิก Show Processes from All Users ที่ด้านล่างของรายการ Task Manager นี่คือสิ่งที่ฉันต้องทำ

1. รีสตาร์ท IIS
2. คลิกขวาที่ไซต์ของคุณ >> จัดการเว็บไซต์ >> เรียกดู
3. กลับไปที่ Visual Studio รีเฟรชรายการกระบวนการ

ลองตรวจสอบที่: "Show Processes for All Users" เมื่ออยู่ในหน้าต่าง "Attach to Process" ที่ด้านล่างซ้ายจะมีช่องทำเครื่องหมาย "Show Processes for All Users"

วิธีง่ายๆที่ใช้งานได้เมื่อ w3wp ไม่ปรากฏในรายการให้เปิดเบราว์เซอร์และเขียน localhost จากนั้นป้อนหลังจากนั้น w3wp จะปรากฏในรายการ

หากคุณใช้บางอย่างเช่น Advanced Rest Client เพื่อทดสอบเส้นทางให้โทรหาเส้นทางของคุณอีกครั้งจากนั้นรีเฟรชรายการกระบวนการและจะปรากฏขึ้น

คุณสมบัติ GoTo Web Project -> เลือก (Web) บนแถบด้านข้างทางซ้าย -> GoTo ภายใต้ส่วนหัว (เซิร์ฟเวอร์) -> คลิกเพื่อดร็อปดาวน์และเลือก "Local IIS"

และนำไปใช้ จากนั้นเมื่อคุณเริ่มการดีบักคุณจะเห็น w3wp.exe ในรายการโปรการเข้าถึง

ฉันเพิ่งพบปัญหานี้ - คุณอาจต้องการตรวจสอบการตั้งค่าโฮสต์ของคุณอีกครั้งและตรวจสอบว่าคุณถูกชี้ไปที่ localhost จริงไม่ใช่เซิร์ฟเวอร์ที่ใช้งานจริง

ฉันลืมไปว่าฉันถูกชี้ไปที่เซิร์ฟเวอร์ระยะไกลดังนั้นแม้ว่าฉันจะเข้าถึงไซต์ แต่ก็ไม่ได้เป็นอะไรในเครื่องดังนั้น w3wp จึงไม่ทำงานแม้ว่าฉันจะมองเผินๆว่าฉันสามารถเห็นไซต์ที่กำลังทำงานอยู่ก็ตาม

ในกรณีของฉันฉันไม่ได้เปิด Visual Studio ในโหมดผู้ดูแลระบบนั่นคือสาเหตุที่ w3wp.exe ไม่แสดงในรายการ

เมื่อฉันเปิด Visual Studio ในโหมดผู้ดูแลระบบมันใช้งานได้

คลิกขวาที่ Visual Studio -> เปิดในโหมดผู้ดูแลระบบ

ในกรณีของฉันเมื่อฉันสร้างโปรเจ็กต์เว็บใหม่และเพิ่มขีด จำกัด ของ Connection Time out (เป็นวินาที) มันจะแสดงในรายการ Debug / Attach to Process โดยอัตโนมัติและทำงานต่อไป

ฉันแค่อยากจะแบ่งปันประสบการณ์ของฉันเช่นกันสำหรับผู้อ่านในอนาคต

โปรดทราบว่าในกรณีที่คุณมีคอนฟิกูเรชันคลัสเตอร์ของเว็บเซิร์ฟเวอร์ (สำหรับการทำโหลดบาลานซ์ ฯลฯ ) w3wpกระบวนการอาจไม่เริ่มทำงานบนเครื่องเดียวกันกับที่คุณคาดหวังไว้

ยกเว้นกรณีที่เว็บไซต์ของคุณมีค่าให้ทำงานเฉพาะในอินสแตนซ์ IIS เดียวที่w3wpกระบวนการอาจจะปั่นขึ้นที่หนึ่งในเครื่องอื่น ๆ ภายในของคลัสเตอร์เว็บของคุณ

นี่อาจเป็นการกำหนดค่าผิดพลาดจากทีม / แผนกเครือข่ายหรือพฤติกรรมที่ตั้งใจไว้ ฉันไม่มีประสบการณ์ที่จำเป็นในการระบุว่าควรกำหนดค่าอย่างไร

พบหน้าที่เกี่ยวข้องบน MSDN เช่นกัน:

https://msdn.microsoft.com/en-us/library/bb742600.aspx

ในกรณีของฉันฉันต้องเชื่อมต่อจาก Visual Studio หนึ่งไปยังกระบวนการที่ทำงานจากหน้าต่าง VS studio อื่น
ปัญหาต่อไป: VS หนึ่งเปิดตัวด้วยสิทธิ์ของผู้ดูแลระบบ สำหรับการแก้ไขปัญหานั้นคุณควรเปิดใช้ทั้ง VS ด้วย Admin perm

ในกรณีของฉันปัญหาคือฉันไม่ได้เรียกใช้ Visual Studio ในฐานะผู้ดูแลระบบ เครื่องของฉันรีสตาร์ทหลังจากการอัปเดตและเปิดใช้งานกระบวนการที่ทำงานก่อนหน้านี้ทั้งหมดอีกครั้ง แต่เพิ่งเปิดใช้ VS ในโหมดที่ไม่ใช่ผู้ดูแลระบบ เมื่อฉันรีสตาร์ท VS ในโหมดผู้ดูแลระบบกระบวนการ w3wp.exeจะพร้อมใช้งานอีกครั้งสำหรับการดีบัก

เรียกใช้ดีบักเกอร์ระยะไกลในฐานะผู้ดูแลระบบ ฉันทำตามทุกคำแนะนำเพื่อแก้ไขปัญหา แต่ก็ไม่ได้จนกว่าฉันจะเรียกใช้ตัวดีบักเกอร์ระยะไกลในฐานะผู้ดูแลระบบที่ฉันสามารถเห็นกระบวนการ w3wp

ลองทำตามขั้นตอนต่อไปนี้:

1. สร้างเส้นทางเสมือนจาก Solution Explorer

2. ไปที่ inetmgr เพื่อยืนยันว่ามีการสร้างพูลของคุณเอง

3. ไปที่ Attach Process (Ctrl + Alt + P) และแสดงกระบวนการสำหรับผู้ใช้ทั้งหมด

4. จากนั้นคุณจะเห็น w3wp.exe จะอยู่ที่นั่น

โปรดทราบว่าแม้จะกระโดดผ่านห่วงเหล่านี้ทั้งหมดแล้ว (เริ่มต้นอินสแตนซ์โดยใช้เว็บเบราว์เซอร์เริ่มเซสชันการดีบักระยะไกลในฐานะผู้ดูแลระบบตรวจสอบให้แน่ใจว่าได้เลือก "แสดงผู้ใช้ทั้งหมด" เป็นต้นเพื่อให้แน่ใจว่าคุณไม่ได้อยู่บนเซิร์ฟเวอร์ ฟาร์ม ฯลฯ ) บางครั้งคุณอาจยังโชคไม่ดี

มีหลายครั้งที่กระบวนการระยะไกลซึ่งโดยปกติจะเป็นบริการ WCF ในกรณีของฉันจะไม่ปรากฏในรายการกระบวนการที่ต้องแนบและไม่มีอะไรที่สามารถทำได้ ฉันระมัดระวังเสมอที่จะทำให้กระบวนการเป้าหมายของฉันสามารถระบุตัวตนได้โดยการเก็บไว้และเฉพาะใน App Pool เท่านั้น บางครั้งคุณก็ไม่สามารถไปจากที่นี่ได้ นี่เป็นสิ่งที่น่าผิดหวังที่สุดอย่างไม่ต้องสงสัยเกี่ยวกับการดีบักระยะไกลที่ Microsoft เคยทำมา