Làm thế nào để chạy ứng dụng C# bên trong một trình biên dịch mã khác với chạy một trình biên dịch mã bên ngoài?

Question

Tôi đang cố gắng hiểu cách trình biên dịch mã (trong trường hợp này là Drone Profiler) chạy một ứng dụng .NET khác với cách chạy trực tiếp. Lý do tôi cần biết điều này là bởi vì tôi có một vấn đề/tham nhũng rất lạ với bản cài đặt .NET của máy tính của tôi. Nó tự biểu hiện bên ngoài profiler nhưng rất lạ bên trong và nếu tôi có thể hiểu tại sao tôi có thể khắc phục vấn đề của máy tính.

Vấn đề CHỈ dường như ảnh hưởng đến các cuộc gọi đến các phương pháp System.Net.NetworkInformation (và chỉ trong phạm vi .NET 3.5 đến 2.0, nếu tôi xây dựng một cái gì đó chống lại 4 tất cả là tốt). Tôi xây dựng một ứng dụng thử nghiệm nhỏ mà chỉ làm một điều, nó gọi System.Net.NetworkInformation.IsNetworkAvailable(). Bên ngoài profiler tôi nhận được "Fatal Execution Engine Error" xuất hiện trong System.dll, và đó là tất cả thông tin mà nó cung cấp. Từ những gì tôi hiểu rằng lỗi thường là kết quả từ các cuộc gọi phương thức bản địa, có lẽ xảy ra khi System.dll cho phép một số DLL gốc thực hiện logic IsNetworkAvailable().

• Tôi đã cố gắng tìm ra sự khác biệt trong và ngoài hồ sơ bằng cách sử dụng Process Monitor, ghi lại các sự kiện từ cả hai tình huống và so sánh chúng. Cả hai bản ghi đều giống nhau cho đến một thời điểm sau khi iphlpapi.dll và winnsi.dll được gọi và ngay trước khi mã trình chạy hồ sơ gọi là dnsapi.dll và mã không phải là profiler đã bắt đầu tải các báo cáo liên quan đến sự cố. Tại thời điểm đó khi nó dường như đi sai mã profiler-chạy tạo ra 4-6 chủ đề mới và mã không profiler (crashing) chỉ tạo ra 1 hoặc 2. Tôi không biết điều đó có nghĩa là, nếu bất cứ điều gì.

---

Có thể cho rằng không cần thiết nền

My Windows 7 bao gồm cài đặt .NET (3,5-2,0) đã làm việc tốt cho đến khi ổ cứng của tôi bị một số tham nhũng và Checkdisk bắt đầu việc tìm kiếm cụm xấu. Tôi chụp ảnh ổ đĩa mới và mọi thứ hoạt động tốt ngoại trừ vấn đề này với .NET.

Tôi cần giải quyết sự cố này khi cài đặt lại Windows hoặc hoàn nguyên về hình ảnh dự phòng.

Dưới đây là một số trong những điều tôi đã nhìn vào:

• Tôi đã diffed các tập tin/thư mục mà dường như phù hợp nhất (những thứ NET trong môi trường Windows và Program Files) trước và đĩa hậu rắc rối và thấy không có thay đổi mà tôi không mong đợi bất kỳ (không có tham nhũng tập tin rõ ràng).
• Tôi đã phân biệt phần mềm và đăng ký hệ thống phát sinh trước và sau sự cố đĩa và không thấy thay đổi nào có vẻ liên quan.
• Tôi đã tạo tài khoản người dùng mới và xóa mọi biến môi trường trong trường hợp có liên quan đến môi trường. Không thay đổi.
• Tôi đã làm "sfc/scannow" và không tìm thấy vấn đề về tính toàn vẹn.
• Tôi đã thử "ngen update" để tạo lại mã được biên dịch trước trong trường hợp tôi đã bỏ sót một thứ có thể bị hỏng và không có gì thay đổi.
• Tôi đã xóa trình quét vi-rút của mình để xem nó có bị can thiệp hay không, không có sự khác biệt.
• Tôi đã thử chạy mã thử nghiệm trong Chế độ an toàn, cùng một sự cố.

Tôi cho rằng tôi cần phải sửa chữa cài đặt .NET của mình nhưng vì Windows 7 có .NET 3.5 - 2.0 bạn không thể chỉ chạy lại trình cài đặt .NET để làm lại.Tôi không có quyền truy cập vào các đĩa Windows để thử cài đặt lại Windows trên chính nó (máy tính có một phân vùng phục hồi nhưng nó không sử dụng được); ổ đĩa cũng sử dụng giải pháp mã hóa toàn bộ đĩa và cài đặt lại sẽ rất khó.

Tôi hoàn toàn không muốn bắt đầu từ đầu và cài đặt Windows mới, cài đặt lại hàng tá gói phần mềm, thử và ghi nhớ hàng chục tùy chỉnh liên quan đến phát triển/v.v.

Cho tất cả những điều đó ... có ai có lời khuyên hữu ích nào không? Tôi cần. NET 3.5 - 2.0 làm việc như tôi là một nhà phát triển và cần phải xây dựng và thử nghiệm chống lại nó.

Cảm ơn!

Quinxy

Answer 1

Câu trả lời ngắn gọn là tệp System.ni.dll của tôi đã bị hỏng, tôi đã thay thế nó và tất cả đều tốt.

Câu trả lời dài có thể giúp đỡ người khác bằng cách tiếp cận của nó với các giải pháp ...

Vấn đề của tôi liên quan đến Net bị hư hỏng trong một cách mà các ứng dụng sẽ không chạy trừ thông qua một hồ sơ. Tôi đã tải xuống mã nguồn cho SlimTune open source profiler, xây dựng nó cục bộ và đặt điểm ngắt ngay trước khi gọi đến Process.Start(). Sau đó tôi so sánh tất cả các tham số liên quan đến việc khởi động ứng dụng thành công thông qua trình hồ sơ so với thủ công. Sự khác biệt có ý nghĩa duy nhất tôi tìm thấy là việc bổ sung các thông số hồ sơ NET thêm vào các biến môi trường:

• cor_enable_profiling = 1
• cor_profiler = {38A7EA35-B221-425a-AD07-D058C581611D}

Sau đó, tôi đã thử cài đặt những thứ này trong môi trường của người dùng của riêng tôi và thì đấy! Bây giờ bất kỳ ứng dụng nào tôi chạy thủ công đều sẽ hoạt động. (Tôi đã thực sự cố gắng làm điều tương tự một vài giờ trước đó nhưng tôi sử dụng một GUID đã được bao gồm trong một ví dụ và không trỏ đến một hồ sơ thực sự và rõ ràng. NET biết tôi đã cho nó một GUID không có thật và không Bây giờ tôi đã quay trở lại và bắt đầu đọc về cách một tập tin PE được thực hiện bởi CLR hy vọng sẽ tìm ra lý do tại sao nó quan trọng là ứng dụng của tôi đã được chạy với tính năng định cấu hình được kích hoạt.Tôi đã học được rất nhiều nhưng không có gì mà dường như áp dụng.

Tuy nhiên, tôi đã nhớ rằng tôi nên kiểm tra lại nhật ký chkdsk mà tôi vẫn liệt kê các tệp đã bị hỏng do lỗi ổ đĩa. Sau khi thất bại tôi đã chuyển tất cả các tập tin được liệt kê id thành đường dẫn tập tin/tên và tôi đã thay thế tất cả hơn 100 tập tin tôi có thể từ sao lưu, nhưng chắc chắn đủ khi tôi trở lại bây giờ và nhìn tôi tìm thấy một lưu ý rằng trong khi tôi đã thay thế 4 hoặc 5. Các tệp liên quan .NET thành công có một tệp như vậy mà tôi không thể thay thế vì nó đã được "sử dụng". Tập tin đó? System.ni.dll !!! Bây giờ tôi đã có thể thay thế tập tin này từ bản sao lưu và cài đặt .NET của tôi đã trở lại bình thường, các ứng dụng hoạt động dù có định dạng hay không.

Điều bực bội là khi sự kiện này xảy ra lần đầu tiên, tôi hoàn toàn có thể gặp sự cố liên quan đến tệp bị hỏng và cụ thể là tệp System.dll chứa các phương thức không thành công. Và vì vậy tôi đã phân biệt và rediffed tất cả các tập tin có tên System.dll. Nhưng tôi đã không nhận ra tại thời điểm đó System.ni.dll là một biểu hiện biên dịch bản địa của System.dll (hoặc somesuch). Và bởi vì tôi đã diffed và rediffed các thư mục liên quan. NET và không nhận thấy điều này (không có ý tưởng làm thế nào tôi bị mất nó) tôi muốn đưa ra trên phương pháp đó.

Dù sao ... dài câu chuyện ngắn, đó là một System.ni.dll bị hỏng gây ra sự cố của tôi, một hoặc nhiều cụm trong đó có nội dung của chúng được thay thế bằng 0x0 và nó chỉ xảy ra để biểu hiện như là vấn đề kỳ lạ quan sát.

Answer 2

Điều này nghe như một vấn đề về thời gian, mà profiler "cố định" bằng cách làm chậm hơn một chút.

Nhiều trình sử dụng thiết bị đo đạc (more info here), điều này làm chậm ứng dụng. Rõ ràng nó làm chậm một sợi chỉ đủ để một luồng khác có thể làm việc nhiều hơn một chút, ngăn chặn sự cố đó. Các lỗi như thế này thường không thể hiện trực tiếp trên máy phát triển, nhưng bề mặt ngay sau khi chúng chạy trên một bộ xử lý có nhiều lõi hơn hoặc siêu phân luồng. Đôi khi chúng chỉ xảy ra trong bản phát hành bản phát hành (hoặc ngược lại trong các bản dựng gỡ lỗi). Các vấn đề về thời gian có thể khó theo dõi vì cùng một mã có thể đưa ra các kết quả khác nhau trong các điều kiện khác nhau (trong trình lược tả hoặc trình gỡ lỗi).

Từ mô tả của bạn, tôi sẽ cố gắng để làm một đoán hoang dã về cách nó có thể được cố định:

Cố gắng tìm thấy trong nguồn nơi các chủ đề mới được bắt đầu. Sau đó, sau khi chúng được sinh ra, hãy thêm một dòng System.Threading.Thread.Sleep(500); vào đó để tạm dừng luồng chính và cho phép một số chủ đề mới bắt đầu.

Nếu không có mã nguồn và một vài dấu vết ngăn xếp của sự cố, điều này là khá một chút phỏng đoán.