Background:
We are hosting a .NET 4.0 Windows Workflow activity inside a WCF service on IIS. The server is a Windows 2008 R2 machine.
Problem:
The ‘Activity’ fails inside the constructor’s InitializeComponent() call with the following stack trace (XamlObjectWriterException). This problem appears to be machine related – i.e. it works on some machines, but fails on others.
Stack Trace :
at System.Xaml.XamlObjectWriter.WriteEndObject()
at System.Xaml.XamlObjectWriter.Dispose(Boolean disposing)
at System.Xaml.XamlWriter.System.IDisposable.Dispose()
at MyActivity.InitializeComponent() in \MyActivityLib\obj\Debug\MyActivity.g.cs:line 81
Has anybody found a similar problem and/or know the cause? I found this Microsoft Connect bug, which gives the same error, but they don't seem to have been able to reproduce it reliably, and it was closed before RTM.)
One of our developers could induce this error when hosting on IIS (Windows XP), while the activity ran flawlessly out of a test console app on his machine. He then deleted his source tree and rechecked it out, and the IIS problem appears to have gone away for him. However, trying the same approach (delete source & re-checkout) hasn't fixed our build server / test environment combination.
Thanks
It turns out that our server was still running .NET 4 Beta 2. Still doesn't explain the problems we had on the developers local machine (definitely running RTM), but oh well - at least it's fixed.
Related
Our web application used the old Crystal Reports XI Rel 2 activeX to render the reports called from classic ASP. We would like now to have it run alongside the new Crystal Reports 13 run time to render reports called from ASP.NET.
We installed the exe found in http://scn.sap.com/docs/DOC-7824 (support pack 3). On our dev machines (windows XP) everything went alright, and we were able to design and render reports in both technologies. We tried to deploy it today to a client's server (Windows Server 2008 64 bit) and it obviously didn't work.
If we first try to open the new report then the old one, they both fail, but with completely generic and therefore useless error messages ones like "Error while creating report". the new one is OK, but the old one fails with message "Invalid TLV record".
Inversely, if, after restarting iis, we first try to open an old report (CR XI R2 from classic ASP), it shows correctly, but the new one (CR 13) gives this error:
Retrieving the COM class factory for component with CLSID
{F734A321-8381-4FFD-A614-139E8906DC83} failed due to the following
error: 80000003 One or more arguments are invalid (Exception from
HRESULT: 0x80000003).
We tried to google this error; the only meaningful result was this thread but it didn't help us.
Thank you
EDIT: ok, the first error was simply that the .rpt files were being left out of the deployed folder. So it really boils down to an incompatibility of the CR runtimes, maybe?
EDIT 2: Yes, it is definitely it. We moved the new report in another virtual directory running under another application pool and now they both work, regardless of what is instantiated first. So is there any way we can gradually migrate our existing records, ie have a period where both run times coexist and are used by the same virtual directory?
I had this problem. As I had just installed CR 13 without a reboot, I thought I'd try a reboot of the server. After the reboot, the problem went away.
I have the same error - reboot didn´t help.
Installed SAP Crystal Reports runtime 13.0.0.99 on Win7 but got several errors registering components during installation - think that is the cause of the problem.
Downloaded and installed CR Runtime 13.0.21.2533 (32bit)
from
https://wiki.scn.sap.com/wiki/display/BOBJ/Crystal+Reports%2C+Developer+for+Visual+Studio+Downloads
http://downloads.businessobjects.com/akdlm/crnetruntime/clickonce/CRRuntime_32bit_13_0_21.msi
That installed without errors but didn´t work either :-(
I have a live standalone server running Windows Server 2008 SP2 (64bit) and IIS7. It is running an ASP.NET website built against .NET 3.5 in its own application pool. Randomly at different times of the day, I get the above error. This may occur once per day, or more. Often when it occurs, it will occur two or three times in relatively quick succession.
Looking at processes and logs leading up to the crash there appears to be no real pattern or specific scenario causing it.
From searches, most recommendations appear to be to get a crash dump and analyse it, however I am struggling to get one.
I have Debug Diagnostics 1.2 installed, and have tried various crash rule setups, but they do not create a userdump. Currently I have a 'Crash rule for all IIS/COM+ related processes' with default advanced configuration.
Can anyone suggest why this isn't creating a crash dump when the issue occurs? Is there another way to get a crash dump?
EDIT: I have installed Debugging Tools according to this useful link and am running ADPlus using this command:
ADPlus -crash -pn w3wp.exe -o c:\ADplusCrashDump
Hopefully I will get a crash dump when it reoccurs . . .
EDIT 2: Found a recursive method call, which caused a stack overflow in rare circumstances. Hopefully that is problem solved. I found another useful link however, see this Blog Post.
Are there any particular settings one should optimally enable/disable/tweak when doing ASP.Net MVC development on local test machine Windows 7 using IIS 7.5 and moving in and out the debugger & recompiling refrequnetly (integration/troubleshooting stage now before TDD fantactics throw stones - although admittedly I could have more under test), I work with 64 bit edition but figure this probably applicable at both x86/x64?
I'll start with one:
Ping Period (seconds) - increase from 90 to 3000 (or something somewhat higher) so you can if unfortunately need to a good bit of time whilst debugging or disable ping on local test machine.
Credit: http://blogs.msdn.com/johan/archive/2007/09/12/my-web-application-times-out-when-debugging-in-iis7.aspx
However I see over stuff such as:
Disable Overlapped Recycle & Recycling settings etc.. that I wonder if could increase performance or make debugging less friction
Question prompted by the annoyance that I've ran across a few recent debugging issues (not apparent in production) including a random, and tempormental error "An assembly with the same simple name blah-blah-lah-assembly-definiton has already been imported . Try removing one of the references or sign them to enable side-by-side." (iisreset resovles) and generally slow debugging attaching. The points and answers to this question need not help with the above (I believe it may be related to spark view engine as that where the stacktrace ends) but figure it worth mentioning incase someone has a direct suggestion *
quick tip: if you're experiencing slow response times (~1-1.5 sec) from browsers other than internet explorer (eg: firefox, chrome, safari) while running your mvc/ other web app on your local machine using win7/vista, it is due to dns resolution with ipv6.
firefox solution: disable ipv6 in about:config (boolean cfg 'network.dns.disableIPv6')
machine wide soft solution: uncomment the good old localhost address in the hosts file (%WINDIR%\System32\drivers\etc\hosts):
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
# ::1 localhost
machine wide hard solution: disable ipv6 completely
credit goes to this blogpost: http://weblogs.asp.net/dwahlin/archive/2007/06/17/fixing-firefox-slowness-with-localhost-on-vista.aspx
Embarcadero guys just published a fresh article on similar topic for Delphi Prism (aka Delphi for .NET), so why not take a look on their suggestions?
http://edn.embarcadero.com/article/40108
From the experience i have working with asp.net mvc, i can tell that there are no special settings for IIS 7 or IIS 7.5 for working on asp.net mvc projects. It works fine in the default form, you just need to create a new website and point it to the folder that has the files for you application.
For debugger if you ask, you can simply put a breakpoint in the code and hit that breakpoint when you run the application from visual studio. But by default the application will use the development web server that fires up when you run a web application from visual studio. If you want to the application to run using the IIS installed on your system you will have to change the project settings. See here for a screen shot of how to do so
http://blogs.bootcampedu.com/blog/post/Debugging-aspnet-mvc-application-using-IIS.aspx
Additionally you can also use System.Diagnostics.Debugger.Break(); for putting a break point in the code.
If you only want to debug your application, I recommend to use the built-in development server of Visual Studio.
If you debugged the most of it or want to do that on IIS, I recommend you the Ctrl+Alt+P shortcut, which enables you to attach a debugger. Select w3wp.exe and you can debug with IIS.
I'm trying to do some web development. I cannot start IIS (I need to run some Web Services).
As of about a month ago, the "COM+ System Application" service has started failing with this error:
The COM+ System Application service
failed to start due to the following
error: Access is denied.
DCOM also logs an error in the event log:
DCOM got error "Access is denied. "
attempting to start the service
COMSysApp with arguments "" in order
to run the server:
{ECABAFBC-7F19-11D2-978E-0000F8757E2A}
When I start IIS and the WWW service, everthing seems to work until I hit port 80 on my machine at which time the IIS/WWW services both crash unexpectedly:
The World Wide Web Publishing service
terminated unexpectedly. It has done
this 1 time(s).
The following event is placed in the application log as well:
The run-time environment has detected
an inconsistency in its internal
state. This indicates a potential
instability in the process that could
be caused by the custom components
running in the COM+ application, the
components they make use of, or other
factors. Error in
f:\xpsp3\com\com1x\src\comsvcs\package\cpackage.cpp(1184),
hr = 80070005: InitEventCollector
failed
I have searched google until my fingers are numb. I've searched this site to no avail as well.
I have tried:
running the COM+ System Application service as an administrator.
reinstalling SP3 for XP
giving the "SERVICE" account full control to %SYSTEMROOT%\Registration
removing XP Security hotfixes installed about the time it stopped working
I've removed and reinstalled COM+ (it's possible, check google)
Any insight on the COM+ subsystem, it's files and settings or just how it operates would be greatly appreciated.
I need to get this problem resolved so I can get back to work.
Have you seen this link?
http://support.microsoft.com/kb/909444
I'm having the same problem, and it appears it might have fixed it for me - though I did have to reboot afterwards which isn't explicitly in the kb instructions.
(Though it's hard to tell right now if this actually fixed it, because sometimes for me the problem would disappear on its own after a reboot (which doesn't make a lot of sense given the steps in the kb)).
Sorry all.
I forgot to update this when I found the solution... Well, it was self-inflicted. Some months ago, I removed the execute permissions from dllhost.exe. I hadn't been coding asp.net web apps at the time so I didn't notice the problem and couldn't put two and two together very quickly.
I eventually found it by turning on file system failed auditing on my Windows folder hive. I saw a mess of access denied messages related to dllhost.exe and remembered what I'd done.
Thanks for the help.
I know there were a couple similar questions, but none solved my problem.
This issue just started within the last couple of days. I don't always hit VS everyday, so I can't say for sure when it began.
When I start debugging, the app loads in IE, but the w3wp process dies with the message
"The program '[9252] w3wp.exe:
Managed' has exited with code 0
(0x0)."
I'm running Vista and debugging on IIS 7 (local machine). VS 2005. This is not a new environment. Everything had worked for months before this issue began.
I've Googled and found a number of solutions. I tried messing with the Process Model settings in the app pool. I tried changing the app pool. I've dug through all the settings of VS I could find that seemed applicable. I am running as administrator. Also, I run VS 2008 as well, and that is working fine.
Update: I tested another app and also had a problem. Though that app was configured to debug on the native VS web server (I forget what it's called off the top of my head), so the error is
The program [7192]
'WebDev.WebServer.EXE: Managed' has
exited with code 0 (0x0).
After about 8 hours of wasted time, I can answer my own question. It's an issue with VS2005/IE8. They, for whatever reason, do not play nice together. I uninstalled IE8 and everything is working fine.
I know Microsoft is a big company, but some interdepartmental communication and testing would be awesome.
I was having this same problem.
According to this Microsoft list of Visual Studio 2005 issues on Microsoft Vista, there are two requirements to fix this issue:
Start Visual Studio with Elevated Administrator Permissions
Make sure that the IIS 6 Compatibility Layer for IIS 7 is installed
The IIS 6 Compatibility components can be added by going to the Control Panel, selecting Programs and Features, and clicking Turn Windows features on or off. Make sure to check the IIS 6 Management Compatibility components under Internet Information Services.
Once I installed these components and rebooted I was able to debug.
EDIT: I still find that the process dies on my from time to time if I have other Internet Explorer browser windows open. Therefore, I have to make sure that the only Internet Explorer window that is open is the one that is debugging my Visual Studio 2005 code. I use FireFox to browse the web in parrallel if I need to.
This can happen if a stack overflow (no pun intended) occurs in your application. Stack overflows are usually caused by infinite recursion in your code.
I had the same problem since an update from latest weeks.
But solved by simply open the develompment tools and set the browser mode to ie7.
I get this if I have an existing IE window open when I start the debugger. Make sure you close all existing IE windows.
Using IE1 and VS 2003 (!) on Win 7 Enterprise N, I found that having additional IEs running made debugging impossible, but when starting the debug session after losing all IE windows worked.
Cost a lot of time and frustration.
I solved the issue on mine, by doing the following:
Go to IIS.
Go to Application Pools.
Click Advanced Settings on the relevant App Pool.
Find the key "Ide Time-out Action" and increase the value to something you think is right for you.