NET-BroadcastEventWindow.4.0.0.0.2982bee.0: CCC.exe — как исправить?
При выключении компьютера появляется окно с предупреждением об ошибке.
Выше: .NET-BroadcastEventWindow.4.0.0.0.2982bee.0: CCC.exe, если вы не нажмете принудительное выключение, компьютер не выключится.
Здравствуйте, Виталий Малиновский.
Прежде всего, обновите драйверы оборудования и BIOS.
Также, если проблема не исчезнет, для устранения и других проблем можно запустить Windows с минимальным набором драйверов и программ. Этот тип загрузки называется «чистой загрузкой». Чистый запуск поможет устранить конфликты программного обеспечения.
Чтобы запустить чистую загрузку Windows, выполните следующие действия:
На рабочем столе нажмите сочетание клавиш Win + X, выберите «Выполнить» и введите:
Нажмите «ОК», если появится запрос на повышение прав, разрешите программе внести изменения в ваш компьютер, откроется окно «Конфигурация системы.
Выберите «Выборочный запуск», снимите флажок «Загружать элементы автозагрузки», перейдите на вкладку «Службы», выберите «Не показывать службы Microsoft», нажмите «Отключить все», нажмите «Применить», «ОК», перезагрузите компьютер.
Если это не сработает, просмотрите эту ветку.
«Машина больше, чем живое существо — Гривус, хотя по этой причине она более опасна».
— Йода.
Net broadcasteventwindow что это
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
- ProfileText
- Sign in
Asked by:
General discussion
In the process of developing a Shell Namespace Extension (NSE) with .NET 2.0 I found that on occasions I would receive the annoying .NET-BroadcastEventWindow problem when a user logged off the workstation. Initial testing proved that this error did come from my NSE but not on every log off. I tried “to search the web using google” as opposed to googling for an answer but found nothing helpful. The best solution I found was to uninstall the .NET 2.0 Framework… after a nano second of thought I decided that probably wouldn’t help so I had to resort to looking into the problem myself – terrible isn’t it!
The most simplistic viewpoint of my application is that there is a client application hosted in explorer.exe as a NSE. This NSE talks to one or more Services hosted as Windows Services through .NET Remoting. The result of these remoting calls are combined to form the contents of the virtual file system that is my NSE.
A quick side note: The .NET GAC and the Recycle Bin are examples of an NSE.
Using Spy++ I noticed many windows registered with this class name, and in many different .NET processes. To make life a little more organized I downloaded SysTree++ and found this extremely useful in determining which processes had a window of that class “.NET-BroadcastEventWindow…” registered. I found that my application (actually explorer.exe as my application is a Shell Namespace Extension) had this window class registered. I noticed that depending on the sequence of events this window would either appear in the same thread as the thread all my Windows Forms instances were created on, but on other times the window was created on another thread. It was in the second situation, when the class was created on an alternate thread that I ran into the broadcast window problem.
Using Reflector I found that this class was registered during the Microsoft.Win32.SystemEvents.Initialize() call in the System.dll. After a quick scan through the code it became fairly obvious that this window is used by the .NET Runtime to capture information about system events such as font changes, color scheme changes and so on. The SystemEvents Singleton instance is only initialized if required, meaning that it is not present in every .NET application, but all Windows Forms applications that have at least one form will have this window. My next step was to determine when this window is created.
Using SysTree++ I watched when this window was created and on which thread. I found that if a Windows Form from my NSE was shown as a result of user action everything was fine. However, if the first Windows Forms window that was created in my application was from a .NET Remoting callback from one of the servers, the window would be created on the alternate thread, the thread of the Remoting call. With that little observation it became immediately clear that the problem was related to which thread the window was created on and more so if that thread was a GUI thread or a background work thread (which the .NET Remoting threads are).
Back to Reflector once again, I noticed that this broadcast window is lazy initialized through a call to one of the static methods of the SystemEvents class, either CreateTimer() or InvokeOnEventsThread(). I decided that all I would need to do is call one of these methods during initialization of my application on the correct thread and internally the broadcast window would be initilalized correctly and everything would be good.
Because my application is an NSE I had a little extra work to establish which thread was a UI thread and where best to place that, but in a normal application this is fairly straight forward. On initialization I added a lovely piece of dodgy code that called the InvokeOnEventsThread(…) method supplying an equally suspicious looking delegate with an anonymous method that does nothing. The point was that I just wanted to call the method to implicitly initialize the broadcast window.
With the help of the IsGUIThread API I added this code to my initialization:
if (!_windowInitialised && NativeMethods .IsGUIThread( false ))
<
Microsoft.Win32. SystemEvents .InvokeOnEventsThread( new FakeMethod ( delegate ()
<
int x = 0;
>));
_windowInitialised = true ;
>
And the result? Well you’ll have to wait for next weeks episode…
Ok, the result: Success! The window went away.
Back to SysTree++, as I hoped for, the broadcast window was created on the correct thread on initialization of my application. From that point on it did not matter what combination of user actions I could possibly imagine, the error was no longer present.
A summary of the problem is that the .NET-BroadcastEventWindow was created on a non UI thread. I will not go as far as to say that this is a .NET Framework but I will say that somebody has got some “splainin to do!”. The problem is not limited to NSE’s, but a general problem with the runtime itself as evident in other applications listed on the net.
Some other points of interest to those trying to fix the same problem are that the apartment state of my NSE is STA. This does have an impact, MTA apartments are treated a little differently. Have a look at the EnsureSystemEvents method of the SystemEvents class and see how the apartment state may affect your product.