My question is general I am not looking for solve a specific error (I have a bunch of them :-)
My BHO is functional, OnDocumentComplete called. In OnDocumentComplete I can execute window.execSrcipt("console.log('Hello');"); etc it works.
I also can run more complex 100 lines of scripts reading them from a stream to the string parameter of execScript method.
My question is: If any script error occurs (any) the COM exception does not contain the original javascript error info, for example the line number.
I've tried to debug the BHO project (it's a C# class lib) and I also tried to use F12 Dev Tools in IE. In the IE console the red error is always the first line of the downloaded html so obviously IE can's catch correctly the injected script context, and the COM exception has no detailed info.
Now how can I get closer info?
When I compile and run my program in Debug mode, everything works as intended. However, when I compile and run in Release mode, things get a little... strange. I receive the following exception if I run the Release mode executable
RemotingException occurred: The async result object is null or of an
unexpected type.
We do use .NET remoting in our application, however, I can confirm this is not a problem with any of my remote calls. This is happening right when I open the program, before I can even step into the Main() method. I have not really been able to find any help on the internet regarding this particular exception/message combination, other than a suggestion about the path being too long (but neither my working copy or the installed copy should have paths long enough to trigger this). Any assistance on this is greatly appreciated, as I'm not entirely sure how to proceed with this error.
Check here: mystery RemotingException raised when changing Platform Target to Any CPU
It seems to change the paths to the DLL's you want to access. Take a look at the paths in the linked question. They are well over 127 chars, and there is nothing you can do about it.
Example:
'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.HostingProcess.Utilities.Sync\10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.HostingProcess.Utilities.Sync.dll
EDIT: Try changing to "x86" and see if the error goes away.
Yes, I have Googled this and found absolutely nothing useful.
I want to use LAME.DLL (NOT LAME.EXE) from C# to turn a WAV into an MP3.
The two CodeProject examples (MP3compressor and Aumpel) that every screen scraping help forum points to are broken. In the EncodeChunk() function, it throws an MSCORLIB engine execution exception right where it calls down to the pointer overload of beEncodeChunk(). The error message almost immediately crashes the VS2005 debugger and I get an uncaught exception running it regularly. Running in debug or release mode doesn't change anything, nor does allowing unsafe code.
The Aumpel CodeProject page says source code updates can be found on his site, but this is untrue as pretty much everything but the Paypal link is missing or broken and there's no telling if purchasing his program grants access to said source code or not.
Has anyone seen any working alternatives to using an ugly command line call or porting the LAME source to C#?
I apologize in advance if this is really a Super User question... I just wasn't sure, but this seems more on the dev. side than on the tech support side. :)
This isn't necessarily a problem, but it does actually drive me totally bonkers on my system. It also only happens on my computer.
When I launch any application, even a blank WPF application, I see four exceptions:
A first chance exception of type 'System.IO.DirectoryNotFoundException' occurred in PresentationCore.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.InvalidOperationException' occurred in PresentationCore.dll
To figure out where these are coming from, I then set VS2008 to break on any thrown CLR exceptions, and here is the information:
Exception #1:
Cannot find a part of the path 'D:\Dell\Reader2.0\SPLASH.SYS\fonts\AscenderUni.ttf'.
Exception #2:
Culture name 'ug' is not supported.
Parameter name: name
Exception #3:
Culture name 'ug' is not supported.
Parameter name: name
Exception #4:
There is no registered CultureInfo with the IetfLanguageTag 'ug'.
I've poked through Process Monitor and Process Explorer. Process Monitor shows that my application is doing a RegQueryValue, which I'm certainly not responsible for... but some DLL (presumably from Dell crapware) is getting loaded by my process and is reading this regkey. I then looked at Process Explorer, hoping to see which DLLs my application is loading, but can't find that info. I then tried PrcView and saw the modules my application was loading.
I was surprised to see how many other modules were getting loaded, but I didn't see anything Dell related. I'm also wondering how it is possible that a Norton Internet Security DLL got loaded into my process, but I assume that's intended and something special that Norton does to ensure that a process is safe to execute.
What else can I do to identify and remove where these exceptions are coming from?
UPDATE
Not sure if it's confusing what I'm getting at here. This exception is raised in a DLL that my application loads for some reason (I don't reference anything Dell-related from my project). I've now uninstalled that app, and I still get the stupid exceptions. It's all technically fine because the exception is handled somewhere, presumably within that DLL, but I'm just annoyed because four extra messages (actually 8, since I have to close two dialogs per exception) pop up when I run my application. Call me lazy, but I never asked this damn DLL to load in the first place. :)
Perhaps now it's time to use msconfig to start disabling some Dell services. I'll play with that later when I actually have free time.
No file corruption. As I've been trying to hunt this one down for a while, I figured out what happened. Somewhere along the way, a font was installed with Uighur culture, which is, apparently a Turkish/Chinese culture (as best as I can tell), and their CultureInfo tag? "ug". When the fonts were cached, the system was attempting to load the Uighur culture. Sadly, my installation of Windows seems to be conspicuously missing this culture in Windows. Knowing that I won't be using the culture on my machine anytime soon, I followed the directions on MSDN to create and install a new culture.
Though the error won't hurt anything major. It is just a first chance exception, after all, it was annoying the crap out of me. So here's what I did.
Create a new console app.
Add a reference to sysglobal.
Add the following code:
var culture = new CultureAndRegionInfoBuilder("ug", CultureAndRegionModifiers.None);
var ci = new CultureInfo("en-US");
var ri = new RegionInfo("US");
culture.LoadDataFromCultureInfo(ci);
culture.LoadDataFromRegionInfo(ri);
culture.Register();
Build.
From Windows Explorer (you need admin privileges to do this), run the compiled executable as administrator.
If all goes well, there should now be a file in C:\windows\Globalization called "ug.nlp".
You shouldn't receive that message again.
I had the same problem.
It disappear after I did:
Clear the WPF font cache and restarted Visual Studio.
Clear the cache: http://support.microsoft.com/kb/937135
Éric
It is very unlikely to be the shovel-ware on your machine. These DLLs need to inject themselves also into non-managed programs, they have to be written in a language that doesn't depend on the CLR, like C or C++. And accordingly cannot generate managed exceptions.
These exceptions look like machine configuration problems to me. Junk in your registry. The bad culture name (sounds like "us" got corrupted to "ug") generates three of them, the font is probably listed in the registry but missing from the disk.
Short from a OS reinstall, you could possibly diagnose this by using both ProcMon and the debugger. Use Debug + Exceptions, Thrown checkbox to force the debugger to stop on the first-chance exception. When it hits, switch to ProcMon, the registry key or file should be visible very near the end of the trace.
With leads from the above answers I was able to solve this issue by deleting the font "Microsoft Uighur Regular"
First chance exceptions are normal - these are displayed whenever an exception is thrown, whether it was handled or not. They exist so you can go into your code and find out why they are thrown.
However, if the exception has been handled, there is no problem and execution will resume.
If the exception was not handled, a second chance exception will be caught by the debugger and execution will halt.
This is normal and shouldn't be of concern. You can always hide them - see this question and answers for more details.
In regards to the actual exceptions - there is some code (third party or your own) that is trying to access a ttf in the mentioned directory, this cannot be found, hence the exception (which was handled, so no problem).
The other exceptions are due to create a non existing CultureInfo (ug) - perhaps this is supposed to be uk? Check configuration and code for this.
These values may be configured in the registry.
I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?
Any ideas guys?
Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.
Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.
To get the full exception, including the stack trace, one of the following should work:
Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it
Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)
Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...
BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.
Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).
For additional info see Dr. Watson vs. CLR.
Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?