WkHtmlToXSharp is C# wrapper (using P/Invoke) for the excelent Html to PDF conversion library wkhtmltopdf library. https://github.com/TobiTonner/WkHtmlToXSharp
I have two websites on staging Windows Server 2008 R2 x64 environment
One of them let say web site A version of website and another one web site B.
The WkHtmlToXSharp conversion was working on the A version but when I set up an B version an conversion not working on that version, I am getting an error:
HtmlToPdf conversion failed: Failed loading page http://website/Convert (sometimes it will work just to ignore this error with --load-error-handling ignore)
I was wondering why it is happening and than I pointed A website to look in to the the same folder as B site is looking. And I was surprised that when I am running A conversion working well there, but when I am ruining B I am still getting the same error, but the funny thing is that both of sites pointed to the same source code(folder). I am just wondering why it is happend. Both websites has the similar app pool configurations and Enable 32-bit apps set too true in bot of them. Also i was trying to set the same app pool for both websites and still the same thing taking place, conversion on site A is working but on B site is not.
On my local environment(Windows 7 x64) if I set the same websites conversions working in both cases.
Also I made some changes in code to ignore the errors :
converter.ObjectSettings.Load.LoadErrorHandling = LoadErrorHandlingType.ignore;
but it is does not fix the error, only the difference is that now I am getting empty pdf in case of conversion on B web site.
I just thinking may be it is something in Windows Server which deny to run/keep in memory two copies of WkHtmlToXSharp.dll or wkhtmltopdf or something kind of like that is going on.
Maybe some one have any ideas about that?
See this https://github.com/pruiz/WkHtmlToXSharp/issues/8
The problem with IIS is that it recycles app. pools from time to time,
but during this process any non-managed resources hold by your
application may (as in this case) end up not being appropiatelly
freed. Also, having more than one AppDomain under you'r IIS
application can cause memory corruption, as both AppDomains try to
instantiante a WebKit instance under the same process (ie. same
process memory/space), and that's another no-way.
The best thing you can do is having a Daemon or Service handling
HTML2PDF conversión, and calling it from your web app. using remoting,
WS calls, or any other RPC method. This will also help you de-compose
your application and making things easier to debug.
Hope it helps.
Related
I've a Perl script that forks in order to use Win32::OLE to extract PNGs of slides from a Powerpoint presentation. I'm in the process of migrating it from my old server (Windows Server 2003) to a new server (Windows Server 2012). The script works fine on the old server (which has Microsoft Office 2010) but on the new server (with Microsoft Office 2016), the script bombs with an error about there not being enough storage available:
Win32::OLE(0.1712) error 0x8007000e: "Not enough storage is available to complete this operation"
I've found quite a few references to this error code, but none particularly useful. Whilst this Microsoft support article says what the problem is and what to do to fix it, I have no idea why this is suddenly an issue now I'm moving to a different server and it doesn't seem to apply to my situation.
The new server has loads of spare disk space and RAM, so there should be plenty to go around. (The old server has far less of both, but that still works.)
Could this be something to do with the new server being 64-bit?
Could it be because of the differing versions of Office?
Could Apache or Perl be configured differently by default than when installed on the old server? (It's a new installation of each, but from the same source as on the old server, and I can't find any configuration that limits memory.)
One interesting point that leads me to believe that it's something to do with the script running via Apache (v2.4.27) is that if I run it from the command line (requiring a minor modification), it works fine. Apache runs as a service and I've tried running it as the same user for which it works on the command line, and that has no impact.
I've run out of places to look and things to try now, so any help would be appreciated.
UPDATE (21 August): Since nobody seems to have any ideas, I refactored my code slightly so that it gets called via a scheduled task. That works fine, supporting my theory that it's something to do with it being run via Apache. I'll keep this question open, partly in case a solution is presented and partly in case my workaround can help anyone else who has a similar problem.
I have an old web application which formerly ran on a windows 2003 server. When I moved it to a new Windows 2008 server, I started receiving an error that I never had before. The app uses a windows login. Upon accessing the app, the user is asked for their login. After that, they are free to use to application. However, the issue is that after using it for some time, the user will be booted out and asked to login again. The system is also much slower than it was previously. It is operating on IIS7. It seems to me that there is a loss of session variables occurring, but I am unsure about why that would be the case.
Interestingly, when the user logs in again, they can generally use the application for a longer period of time before being booted out and asked to log in again. It is also worth mentioning that it seems like the more users there are on the server, the less prominent the issue is.
It is also worth mentioning that I tried moving the application to another 2008 server, and it worked perfectly fine on that one. This leads me to believe that the issue lies somewhere in the settings on the server. I looked at the settings of the two 2008 servers side-by-side and noted the differences, but was incapable of finding a difference that would cause this sort of error. One difference that might be worth noting is that the server which does not work properly is 32 bit, whereas the server which does works is 64 bit. Although, I don't see how that difference could lead to the application having a loss of session variables, but still working otherwise.
Additional information:
The code in the application on each server is identical, so that leads me to believe that the error is on the server level and not within the application itself.
Given that the code is identical, I do not believe this to be a result of Session.Abandon() being called from anywhere.
I do not believe this is due to a session timeout.
I have read that other people experience a loss of session variables due to app pool recycling, and that often the app pool recycling is from the config files being accessed (whether it be from a user or from something like an anti-virus software). I have no reason to believe that this is the case here, because all servers are under the same anti-virus and the application works fine on them.
On the server which works, the IIS authentication setting are set such that windows authentication is disabled and that anonymous authentication is enabled. Whereas, on the other server, the opposite is true.
Any help with this issue would be appreciated.
Thank you.
Make sure your app pool is running under 4.0 .Net Framework and also check your application pool identity. When your using 7.0 iis, make sure you use integrated mode.
Every time I build my solution and try to start debugging, I get this message:
Unable to start debugging on the web server. The web server did not respond on a timely manner. This maybe another debugger is attached to the web server.
If I restart my IIS, I can start debugging but If I build again I have to restart my IIS again. I saw several people having same issue but no one same as mine exactly.
Open your cmd in administrator mode and run cmd
iisreset
The below link contain some useful answers:
Unable to start debugging on the web server. Could not start ASP.NET debugging VS 2010, II7, Win 7 x64
Like this answer:
1)
Try going to IIS and checking to make sure the App Pool you are using
is started. A lot of times, you will produce an error that shuts down
the app pool. You just need to right click and Start and you should be
good to go.
2) And this answer
Turns out that the culprit was the IIS Url Rewrite module. I had
defined a rule that redirected calls to Default.aspx (which was set as
the start page of the web site) to the root of the site so that I
could have a canonical home URL. However, apparently VS had a problem
with this and got confused. This problem did not happen when I was
using Helicon ISAPI_Rewrite so it didn't even occur to me to check.
I ended up creating a whole new web site from scratch and porting
projects/files over little by little into my solution and rebuilding
my web.config until I found this out! Well, at least now I have a
slightly cleaner site using .NET 4.0 (so far, hopefully I won't run
into any walls)--but what a pain!
I have a ActiveX control hosting a flash-player which is in turn running a flash file trying to access data from a web-address.
In an old Windows Application version of my application everything works fine and the flash file is able to access the web-content.
However, in a newer Console Appliction version of the application it can no longer access the web-content.
Any ideas what might be causing this? Is there some kind of difference between a Windows Application and a Console application in terms of security/permissions that might affect an ActiveX hosted flash-player?
I'm using Windows 7.
First of all - how did you manage to get an ActiveX into a console application? :) I think ax needs window handles and all such things...
Anyways, there are different kinds of sandboxes from the Flash player perspective, what you are seeing is the "local not trusted" kind. In order to "trust" the SWF that issues the request you would need to use this page to confirm that the location where SWF comes from can communicate to the internet.
Doing so may be a hindrance for the user, but if this is the case, you could write the trust files on your own. Example
I made a minor change to a legacy Visual C++ / MFC app built with VS 2008. I changed some UI resources in the .rc file and compiled without any problems, then deployed it on my client's system. However, the program which was previously doing fine now fails to run on exactly one of their servers. It works fine on my laptop and on their other servers, many of whom are basically identical to the one having the trouble.
The weird thing however is that there is absolutely no error message whatsoever. No message box, no errorlevel set (when run on command prompt), no Dr. Watson entry, no nothing.
It's an MFC app that does not really comprise anything very special. It does link in some external libraries – e.g., some old version of the Xerces C++ XML parser. But this is probably not too relevant, right?
The program has a class derived from CWinApp, and I tried to add some logging in its constructor. Based on this, it looks like not even this constructor is reached.
The server in question is running Windows Server 2003 Standard Edition Service Pack 2, and we are trying to run the program in a Remote Desktop session. (Because of the client's environment, I cannot easily test in a console session right now.)
I reverted my changes from version control, which did not help – but I do not know if I had built myself the previously installed version (which ran just fine even on this server) or if it had been built by someone else.
Have also tried to reinstall the Visual C++ runtime libraries and of course reboot Windows, but neither helped. Now I'm really running out of ideas... Any clues on what I could try or check?
Probably some error occurs but is surpressed e.g. empty catch() statement or similar.
You could try and install Debugging tools for Windows WinDbg to see if you could get more info when trying to run it. Since the download is rather small 25Mb maybe it is possible to install it on your client's PC.
But first check the eventview log for your app, maybe there is something in there that can shed some light.