When was MS Message Queue first released?
http://en.wikipedia.org/wiki/Microsoft_Message_Queuing
Since Windows NT 4.0 and Windows 95, so 1995-ish.
It looks like NT 4 Option Pack 3 was the first release of MSMQ. That puts the technology in May of 1997.
Related
I had an application perfectly working under Windows XP (32 bit). Moving to Windows 7 (64 bit) and compiling gives me the error run time error 429 ActiveX component can't create object in the module (second line, "set mydb=...", see code) where I make the connection with the MS Access database (Access 2013 in Windows 7 64 bit). In Windows XP it was an Access 2000 database with extension .mdb. Now it is Access 2013 with extension .accdb.
In the references I replaced the Microsoft Office DAO 3.5 library with the Microsoft Office 15.0 Access Database Engine Object Library, but this doesn't solve the problem. (If I leave the DAO object library, then I get run time error 3343 unrecognized database format on the same line.)
I'm not sure if I have to put in the components of the forms the 32 or the 64 bit version. (For example, dbrgid32.ocx under windows\system32 or under windows\sysWOW64 ... or does it not matter?)
Sub pldata()
Set mydb = DBEngine.Workspaces(0).OpenDatabase("D:\ETC\Gegevens\ETC2015.accdb", False, False, "MS Access")
'Set mydb = DBEngine.Workspaces(0).OpenDatabase("D:\ETC\Gegevens\ETC2015.accdb")ess")
Set myrstadres = mydb.OpenRecordset("select * from dbadres order by naam")
End Sub
I'm working with WinDbg 6.12 with both serial port connection and named pipe connection. Unfortunately I'm unable to connect my WinDbg with the target (NT 4 SP 6a) from the begining of the OS boot, autoreconnect doesn't work and I need to wait until NT 4 timeout for kernel connection is reached. Then NT continues with the startup process and only then I can connect...
Where I can get a version fully compatible with NT 4? (I have already checked the oldest version from Microsoft Debugging Tools website)
Also, where can I get the NT 4 symbols for debugging? I'm afraid the Microsoft Symbols Server doesn't provide these symbols anymore.
Thanks,
For futher details, the kd log is:
Opened \\.\pipe\com_1
Waiting to reconnect...
Connected to Windows NT 4 1381 x86 compatible target at (Tue Jan 24 16:32:17.010 2012 (UTC + 1:00)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: srv*b:\out*o:\out*http://msdl.microsoft.com/download/symbols
Executable search path is:
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
CS descriptor lookup failed
Windows NT 4 Kernel Version 1381 UP Free x86 compatible
Machine Name:
Kernel base = 0x80100000 PsLoadedModuleList = 0x80150b70
System Uptime: not available
The call to LoadLibrary(kdextx86) failed, Win32 error 0n2
"El sistema no puede hallar el archivo especificado."
Please check your debugger configuration and/or network access.
Unable to get program counter
WaitForEvent failed
Unable to get program counter
0008:497a 0010 add byte ptr [bx+si],dl
kd>
Works with http://msdl.microsoft.com/download/symbols/debuggers/dbg_amd64_6.7.05.1.exe
From Windbg 6.12 help:
"Windows NT 4.0
Debugging Tools for Windows no longer supports the debugging of Windows NT 4.0 targets.
If you want to debug a Windows NT 4.0 target computer or perform user-mode debugging on Windows NT 4.0, you should use Debugging Tools for Windows version 6.7.5.1. You can install this package from the Debugging Tools for Windows Web site."
We've recently started seeing spikes in the thread counts on our tomcat servers (peaking at over 1000 when normally at around 100). We performed a thread dump on one of the tomcat servers whilst it's thread count was high and found that a large number of the threads were waiting on MultiThreadedHttpConnectionManager$ConnectionPool, stack trace as follows:
"TP-Processor21700" daemon prio=10 tid=0x4a0b3400 nid=0x2091 in Object.wait() [0x399f3000..0x399f4004]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x58ee5030> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.doGetConnection(MultiThreadedHttpConnectionManager.java:518)
- locked <0x58ee5030> (a org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ConnectionPool)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager.getConnectionWithTimeout(MultiThreadedHttpConnectionManager.java:416)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:153)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
...
There are 3 points in our code where httpClient.executeMethod() is called (to obtain info via an http request to another tomcat server). In each case the GetMethod object passed to it has had its socket timeout value set (i.e. via getMethod.getParams().setSoTimeout();) before hand, and the MultiThreadedConnectionManager is configured in spring to have a connectionTimeout value of 10 seconds. One thing I have noticed is that only 2 of the 3 httpClient.executeMethod() invocations are followed by a call to getMethod.releaseConnection(), so I'm wondering if this may be the cause of the problem (i.e. connections not being explicitly released). However what's strange is that
the problem has only started occurring in the last few days and the source code has not been modified for over a year, plus the fact that there has been no recent surge in requests coming through to the tomcat servers. One change that did occur a couple of days before the problem started to occur was that we upgraded the JVM used by the tomcat server from Java 5 (1.5 update 14) to Java 6 (1.6 update 25). We have tried temporarily reverting the JVM version to Java 5 to see if the problem stopped occurring but it did not. Another point to note is that in most cases the tomcat server eventually recovers and
the thread count drops back to normal - we've only had one instance where a tomcat process appears to have crashed because of the thread count increase.
We are running Tomcat 5.5 with commons-httpclient-3.1.jar running against a Java 1.6 update 25 on a Red Hat linux environment.
Please let me know if you can suggest any ideas as to what may be the cause of this issue.
Thanks.
The problem was indeed caused by the fact that only 2 of the 3 httpClient.executeMethod(getMethod) invocations were followed by a call to getMethod.releaseConnection(). Ensuring all 3 httpClient.executeMethod(getMethod) invocations were inside a try/catch block followed by a finally block containing a call to getMethod.releaseConnection() prevented the high thread counts from occurring. Although this code had been in our live system for over a year, it appears that the reason the high thread count issue only recently started occurring was because various search engine crawlers had started hitting the site with lots of URL requests that caused the code where the connection was being used but not subsequently released to execute. Problem solved.
I've been trying to get the Citrix XenApp client going - but as soon as it connects it crashes on Windows 7 64bit. Citrix support has 0 information on Windows 7, so I'm curious if others have gotten it to work, of it's just me.
thx.
CDViewer has stopped working
Description:
Stopped working
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: cdviewer.exe
Problem Signature 02: 11.2.0.31560
Problem Signature 03: 4aac18be
Problem Signature 04: DesktopViewer
Problem Signature 05: 11.2.0.31560
Problem Signature 06: 4aac18ba
Problem Signature 07: 105
Problem Signature 08: 80
Problem Signature 09: System.IO.InvalidDataException
OS Version: 6.1.7600.2.0.0.256.48
Locale ID: 1033
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
Found a workaround.
It has something to do with the version of Citrix that we're using on the server vs. the latest client version.
The workaround is rather simple, in Windows 7 you need to associate the ".ica" extension with C:\Program Files (x86)\Citrix\ICA Client\wfica32.exe program.
There's a hotfix for this, it has to do with the size of the Terminal Server public key, see
Citrix ICA clients may crash when they are connecting to a Windows Server 2008-based terminal server that has Citrix Presentation Server installed
Loading Dump File [C:\Crash_Mode__Date_12-05-2009__Time_15-54-2727\PID-4056__CCNET.EXE__1st_chance_Process_Shut_Down__full_13d0_2009-12-06_00-33-14-734_0fd8.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: '1st_chance_Process_Shut_Down_exception_in_CCNET.EXE_running_on_TEST218'
Symbol search path is: srvE:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
Windows Server 2003 Version 3790 (Service Pack 2) MP (2 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Sun Dec 6 00:33:14.000 2009 (GMT+8)
System Uptime: 32 days 12:43:52.414
Process Uptime: 0 days 8:44:37.000
..........................WARNING: mscorjit overlaps mscoree
..............................WARNING: wldap32 overlaps dnsapi
..........WARNING: rasapi32 overlaps dnsapi
...WARNING: tapi32 overlaps rasapi32
.WARNING: rtutils overlaps rasman
..............WARNING: setupapi overlaps winsta
....wow64cpu!CpupSyscallStub+0x9:
00000000`78b842d9 c3 ret
why this happen?
Not related to CLR, instead it's 32-on-64 as described here http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/ -- in short use the following:
.load wow64exts
.effmach x86
With those, kb and !analyze -v will give better results.
I hadve seen the same thing latly, I do not know for sure but it's probably some WOW64 artifact or possibly due to some more aggressive anti-exploitation techniques. At leat on Win32, even though the load address of a DLL may be different on occasion, if a DLL is mapped in antother process (like ntdll/kernel32) when your process start's if it is statically linking these DLL's also, it would always load at the same address until the next reboot.
It seems probable that more recent CLR exe's are able to remap various module's per-execution, I know that this is an issue on MSVC10 and Windows7 but perhaps it's been ported to additonal platforms for CLR applications.