I am running Microsoft POS for .NET. I have a cash drawer, barcode scanner and receipt printer connected to the computer. Using the Microsoft POS for .NET test application, they all work fine.
Our application is an ASP.NET web application, in IIS. We thus instantiate the OPOS devices from the server-side of the web application, and everything works fine. We've been doing this since Windows XP / IIS 5.1.
We're now upgrading our deployment computers to Windows 7. Our development computers run this scenario without issue. However, on the deployment computer I am currently working with, I have had two issues:
Issue 1)
The barcode scanner hangs on the Open() method. It freezes there and never terminates. I discovered that if I changed the permissions (full access to everyone) on the following files, the scanner would start working.
Symbol control object-OCX c:\WINDOWS\system32\scanner.ocx
Service Object-DLL c:\WINDOWS\system32\stiopos.dll
Issue 2)
The cash drawer is now presenting similar behaviour: it freezes on the Claim() method. I have changed permissions on all the files I could find (even loading up sysinternal's Process Explorer) to find which files were in use. This has not solved the problem.
Notes:
IIS is now running as SYSTEM in my tests - it makes no difference.
The hardware works fine in Epson OPOS and the Microsoft POS for .NET test tool. Therefore, the issue is only when running within the context of a web application.
The application uses c:\program files\OPOS\CommonCO\OPOSCashDrawer.ocx and c:\program files\OPOS\Epson2\SoDrw14.dll
Have you ever seen this behaviour? Do you have any suggestions on how to solve it?
Stack trace when hangs:
Microsoft.PointOfService.dll!Microsoft.PointOfService.Legacy.LegacyProxy.InvokeMethod(string methodName = "ClaimDevice", ref object[] parameters, bool[] byRef) + 0x94 bytes
Microsoft.PointOfService.dll!Microsoft.PointOfService.Legacy.LegacyProxy.InvokeMethodAndCheckImpl(string methodName = "ClaimDevice", ref object[] parameters, bool[] byRef) + 0x50 bytes
Microsoft.PointOfService.dll!Microsoft.PointOfService.Legacy.LegacyProxy.Claim(int timeout) + 0x54 bytes
Microsoft.PointOfService.dll!Microsoft.PointOfService.Legacy.LegacyCashDrawer.Claim(int timeout) + 0xd bytes
Solution: Switch the app pool to Classic mode (instead of Integrated). It works like a charm now!
Related
I am trying to see the raw response message returned from a call to an internet-connected web API. The calling code looks like this:
object[] results = this.Invoke("MethodName", new object[] { requestObject });
The problem is that while debugging, the results variable already appears completely deserialized, for example the date property I'm interested in is already a DateTime type.
So I did the following:
Turned off "Enable Just My Code".
Turned on "Enable .Net Framework source stepping".
Enabled symbol loading and ensured that the System.Web.Services module has had symbols loaded ("Symbols loaded."):
System.Web.Services.dll
C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Web.Services\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Web.Services.dll
C:\Users\user\AppData\Local\Temp\SymbolCache\System.Web.Services.pdb\312122031d1b4f30b59771eb845018121\System.Web.Services.pdb
I dropped a breakpoint inside of the following method starting on line 163 of SoapHttpClientProtocol.cs (the one called by my client code):
protected object[] Invoke(string methodName, object[] parameters)
I started debugging the project and used my UI to trigger the code that makes the request. When I get to the Invoke line above and press F11, it tries to remote debug and step into the remote server:
Microsoft Visual Studio
Unable to automatically step into the server. Connecting to the server machine 'api.example.com' failed. The Visual Studio 2015 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.
Note: I have no desire to do remote debugging, I just want to step into the .Net code.
After hitting OK, it goes to the next line in my client code without either stepping into the .Net library or hitting my breakpoint.
When I look at the breakpoint in break mode (instruction pointer still on line after the calling Invoke line), it is a hollow circle and says "This breakpoint will not currently be hit. No symbols have been loaded for this document."
This makes no sense as the symbols have been loaded, as proven above.
How do I either step into the .Net source code, or perform this request via another means? This particular request is a bit more complicated than some, as it requires a certificate (.pfx file) as well as a username and password.
Hmmmmm... one data point is that the breakpoint I dropped is in a file which says at the top:
// Decompiled with JetBrains decompiler
// Type: System.Web.Services.Protocols.SoapHttpClientProtocol
// Assembly: System.Web.Services, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// MVID: A6D697F9-972E-41EC-820F-E59621A808B5
// Assembly location: C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Web.Services.dll
It suddenly seems to me that this is where the discrepancy may be coming from. Is JetBrains interfering with my stepping into .Net source?
Unable to automatically step into the server. Connecting to the server machine 'api.example.com' failed. The Visual Studio 2015 Remote Debugger (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer.
So actually you just debug your web app locally, but you got the remote debugging error/warning, am I right?
Like this document here:
https://msdn.microsoft.com/en-us/library/ms164726.aspx?f=255&MSPPError=-2147217396
If you are getting this message while you are debugging locally, your anti-virus software or a third-party firewall may be to blame. Visual Studio is a 32-bit application, so it uses the 64-bit version of the remote debugger to debug 64-bit applications. The two processes communicate using the local network within the local computer. No traffic leaves the computer, but it is possible that third party security software may block the communication.
In addition, you use the correct steps to debug the .NET Framework source code after your discussions:
But if you use the VS2015, you need to think about that whether the Reference source has been updated for the .NET framework:
Cannot step into .NET framework source code
A user voice here:
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/6886255-please-keep-the-reference-source-symbol-server-upd
I have an ASP.NET website I migrated/converted from classic asp to v4.0
There is a 3rd party DLL which is used and I need to register it using regsvr32.
Now all of this works just fine on my local dev environment but also on a test webserver. My environment runs WS2008R2 Enterprise + all updates and iIS 7.5
The test environment using WS2008R2 Std + all updates and IIS 7.5
I have created several virtual machines with a plain environment to test deployment and that works fine.
The live one however causes a problem. That is running WS2008 Std + updates and IIS 7.0.
When getting to the page in question, I get a runtime error and NO idea where to go about this:
Unable to cast COM object of type 'TAMOnlineUtils.clsMainClass' to interface type 'TAMOnlineUtils._clsMain'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{B0B5FC90-90A9-4DD9-A4C6-D779C905B322}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
at System.StubHelpers.StubHelpers.GetCOMIPFromRCW(Object objSrc, IntPtr pCPCMD, Boolean& pfNeedsRelease)
at TAMOnlineUtils.clsMainClass.GetCertFileList(Object& sPath)
at TAMOnlineWebsite.Report.CalDisplay.DoDisplayCertAndData()
Any ideas anyone? Completely stumped.
Problem fixed.
There seemed to have been a culprit of the same DLL (perhaps different version) but located in C:\Windows\System32
Not sure why or how that was done but after unregistering that DLL and then deleting the DLL, everything seemed to have worked just fine.
Regression testing is being done on other possible apps affected by the removal of that DLL but it appears its all working fine.
So yes, a conflict there!
Got some strange problem.
I'm developing some complicated Web Services network that uses some VB6 .dll. In my previous post I got some problems with the dll but we've solved them.
So, the new problem is:
When I debug my service (those which uses VB6 dll) on development server from visual studio - everything works fine, the problem starts when I publish my service on IIS (I tried my local IIS). After that, when I call .dll method (as I understand I need to call it by reference - and that's what the compiler tells me) I got an exception:
"System.Runtime.InteropServices.COMException (0x800A000D): Type mismatch at ..."
Actually is happens here in the third line:
Object s = (Object)OrderId;
Object s1 = (Object)lines.Length;
proxy.OrderRead(ref s, ref s1);
OrderId and Legth are integers.
As I understant this is exception that comes from the .dll from vb6 :/
What the problem may be? Why it runs when debugging but fails on IIS?
When debugging in vb6,the IDE will register the dll for you. After publishing, have you may ahve to register your vb6 dll on the server. Open a command prompt and change to the location of the dll and run regsvr32 myvb6.dll.
Also, check these settings.
http://support.microsoft.com/kb/281630
I'm wondering if anyone else has experienced failed DLL's after upgrading their servers.
My company is in the process of upgrading our code and server's after ten years of using classic ASP. We've set up our new server running Windows 2008 and IIS 7. Our classic ASP code and our new asp.net mvc code work pretty well.
Our problems started happening when we began moving our old websites to the new server. When trying to load the page on the actual server machine's browser, we initially got a 500 error. If we refreshed the page then some of the page would load but then display an error:
Server object error 'ASP 0177 : 800401f3'
Server.CreateObject Failed
/folder/scriptname.asp, line 24
800401f3
btw: On remote machines we would just get 500 errors.
Line 24 is the first executable code in the script:
'23 lines of comments
set A0SQL_DATA = server.createobject("olddllname.Data")
'the rest of the script
That specific line is trying to use a ten year old DLL to create a server object. I don't think the server configuration is a problem because I'm able to create "adodb.recordset" server objects without any problems.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Is there a way to get old DLL's working on 64 bit systems?
Edit
I have confirmed that the site's application pool is running in 32bit compatability mode, but the site still sends the same errors whenever set A0SQL_DATA = server.createobject("olddllname.Data") is called.
Is there an issue when running correctly registered old DLL's on 64 bit systems?
Yes, the most prominent example of a 32-bit DLL no longer working on 64-bit Windows seems to be the Microsoft Jet Engine, i.e., the driver required to access .mdb files. Since there is no 64-bit version, the only way to access .mdb files in classic ASP application is to run IIS (or the Application Pool, to be precise) in 32-bit compatibility mode.
How to detect if you are in 32 or 64 bit mode (untested):
Set shell = CreateObject("WScript.Shell")
Response.Write shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%")
This should output AMD64 in 64-bit mode and x86 in 32-bit mode (either native 32-bit or 32-bit emulation on a 64-bit processor).
Well, error 800401f3 means "invalid class name." That strongly suggests that the DLL is registered with the wrong ProgId (or that the ProgId is missing entirely). When your sys admin verified that the DLL was registered, did he also verify that its ProgId is "olddllname.Data"?
We're seeing an odd pattern in our QA Lab. We have two ASP.NET applications, each deployed on the same Windows 2008 SP2+ box. We have our App Pool running in a Domain Account, and set to never re-cycle. The same 1 App Pool is used by both applications.
After several hours of running fine, new users surfing to a page in our application get the IIS7 Error Page, with a 500.21 error.
If we do nothing but:
1) IISRESET
2) Change folder to c:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and "rd" the 2 applications.
And then surf to our web applications, all is fine.
Then several hours later, however, the 500.21 errors return.
What strikes me as odd is the seeming relationship between clearing the "Temporary ASP.NET Files" folders and the problem going away. I've a practice of clearing the "Temporary ASP.NET Files" folders when installing a new version of our application(s), but not otherwise.
Does this relationship ring familiar to anyone? Is there some new-ish IIS7 feature at work here?
Text of Error:
Server Error in Application "DEFAULT WEB SITE/PAIS"
Internet Information Services 7.0
Error Summary
HTTP Error 500.21 - Internal Server Error
Handler "PageHandlerFactory-Integrated" has a bad module "ManagedPipelineHandler" in its module list
Detailed Error Information
Module IIS Web Core
Notification ExecuteRequestHandler
Handler PageHandlerFactory-Integrated
Error Code 0x8007000d
Requested URL http://localhost:80/PAIS/Admin.aspx
Physical Path C:\0_Georgia\GA_IS_100142\PortfolioArchiveImageServer\Admin.aspx
Logon Method Anonymous
Logon User Anonymous
Most likely causes:
• ASP.NET is not installed or incompletely installed.
• A configuration typographical error occured.
• Unfavourable pre-condition evaluation exists.
Things you can try:
• If ManagedPipelineHandler is missing, ensure that:
o ManagedEngine is in .
o ManagedPipelineHandler is in , with correct pre-conditions.
• Install ASP.NET.
• Ensure all system.webServer/handlers#modules are in system.webServer/modules#name.
• Review pre-conditions in the and sections.
Links and More Information IIS core does not recognize the module.
View more information »
Thanks in advance,
Howard Hoffman
Faced the same problem and the fix was easy.
1) Open visual studio 2010 command prompt.
2) Run the command aspnet_regiis.exe -i
We found the actual problem, with MS ASP.NET support's help. It's pretty subtle. I think MS has said they will fix the issue in a follow on to the App Fabric release (which is now RTM). Fingers crossed.
The problem consistently occurs in this scenario:
1) ASP.NET web application not yet running. It includes WCF Net.Pipe and / or Net.Tcp bindings. I think the same would occur for NetMsmq but did not try it.
2) An inbound NetPipe or NetTcp WCF Windows Activation Service request is the initial request that starts the App Domain.
3) Application uses an 'Integrated' IIS App Pool (IIS7 or IIS 7.5)
4) The application uses HttpServerUtility.Execute during that 1st request.
It turns out that our application was firing an ASP.NET Health Monitoring event during the very 1st WCF operation -- the very operation that caused Windows Activation Service (WAS) to start our application. Our Health Monitoring configuration includes the TemplatedMailWebEventProvider.
Our application is using an 'Integrated' IIS App Pool.
The TemplatedMailWebEventProvider is implemented to create an email message body as HTML. It uses the System.Web.HttpServerUtility.Execute(string, TextWriter, Boolean) overload.
For this use case that overload does the wrong thing -- it initializes a 'Classic' IIS App Pool based HTTP pipeline. Because that's the wrong pipeline for an 'Integrated' IIS App Pool the pipeline gets corrupted with the next HTTP request -- which is actually the first inbound HTTP request.
So you get the 500.21 error for all future HTTP requests until the application is re-cycled. You don't need to perform the relatively drastic steps of IISRESET, clearing Temporary ASP.NET cache to clear up the error -- just restart the app via saving web.config and avoid the particular startup path that causes the error.
MS suggested a workaround for us -- use the SimpleMailWebEventProvider instead of the TemplatedMailWebEventProvider. That does work, since it takes HttpServerUtility.Execute out of the code path for the first request.
I'd suggested that MS introduce a new web.config <system.web> boolean setting -- UseIntegrated -- that let's the application specify the typeof App Pool to initialize with. Evidently IIS does not forward the App Pool type to ASP.NET, so my sugggestion is a work-around to that.
The TemplatedMailWebEvent provider is much more user friendly than the SimpleMailWebEventProvider, and we do hope MS addresses the issue.
Thanks all for reading,
Howard Hoffman
1. IIS 7 throws an exception as shown in below
2. Open visual studio 2010 command prompt in Administrator mode and execute aspnet_regiis.exe -i
3. Problem fixed, as shown below ASP.Net Application and ASP.Net MCV Application are running smoothly.
The problem more likely is in the application code. The Temporary ASP.NET Files folder contains pre-compiled copies of your app and will be refreshed every time the applications files are accessed. You can pre-compile these files with aspnet_compiler.exe in the \Windows\Microsoft.NET\Framework\v2.0.50727\ folder. Use the -errorstack option allow for more information to be generated about the error you are getting. Long running applications that don't recycle will run into problems if they use a lot of memory or retain large amounts of data in an inproc session state. if your sessions contain large amounts of information, consider using a sqlserver-based session manager.