I'm having an issue with writing to a serial device in UWP. My task for writing to the port looks like this:
public async Task WriteAsync(byte[] stream)
{
if (stream.Length > 0 && serialDevice != null)
{
await writeSemaphore.WaitAsync();
try
{
DataWriter dataWriter = new DataWriter(serialDevice.OutputStream);
dataWriter.WriteBytes(stream);
await dataWriter.StoreAsync();
dataWriter.DetachStream();
dataWriter = null;
}
finally
{
writeSemaphore.Release();
}
}
}
The code works fine the first two times I call this function. The third time I get Unhandled Exception in ntdll.dll in the await dataWriter.StoreAsync() line.
The full exception I can see is:
Unhandled exception at 0x00007FFCB3FCB2C0 (ntdll.dll) in xx.exe:
0xC000000D: An invalid parameter was passed to a service or function.
This answer mentions a garbage collector closing an input stream, however I don't see why would it happen in my code. Any help on getting to the bottom of this issue would be highly appreciated!
Turns out the solution to my problem was in another piece of code. I had a function reading the bytes like this:
private async Task ReadAsync(CancellationToken cancellationToken)
{
Task<UInt32> loadAsyncTask;
uint ReadBufferLength = 1024;
// If task cancellation was requested, comply
cancellationToken.ThrowIfCancellationRequested();
// Set InputStreamOptions to complete the asynchronous read operation when one or more bytes is available
dataReader.InputStreamOptions = InputStreamOptions.Partial;
using (var childCancellationTokenSource = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken))
{
// Create a task object to wait for data on the serialPort.InputStream
loadAsyncTask = dataReader.LoadAsync(ReadBufferLength).AsTask(childCancellationTokenSource.Token);
// Launch the task and wait
UInt32 bytesRead = await loadAsyncTask;
if (bytesRead > 0)
{
byte[] vals = new byte[3]; //TODO:adjust size
dataReader.ReadBytes(vals);
//status.Text = "bytes read successfully!";
}
}
}
Specifically the problem was in the following two lines:
byte[] vals = new byte[3]; //TODO:adjust size
dataReader.ReadBytes(vals);
As soon as I set the size of the vals array to bytesRead value the problem went away.
Normally, you would not have to set dataWriter to null, because the GC will know that an object will not be used anymore.
You'd better call dataWriter.Dispose() method like many UWP samples.
For example: SocketActivityStreamSocket
Please read IDisposable.Dispose Method () document for more details.
Related
I have this code that is asynchronously splitting a file into parts, and downloading them using HTTP content range. It then writes the downloaded data to a ViewStream on a Memory Mapped file. I am currently reading from the response stream into a buffer, then writing all the data from the buffer into the ViewStream. Is there a more efficient/faster way to do this? I am not really concerned about memory use, but I am trying to maximize speed. Pieces is a list that contains value tuples indicating the (Start, End) for the piece of the file, and httpPool is a object pool with a bunch of preconfigured HTTP Clients. Any help is greatly appreciated, thank you!
await Parallel.ForEachAsync(pieces,
new ParallelOptions() { MaxDegreeOfParallelism = Environment.ProcessorCount },
async (piece, cancellationToken) =>
{
//Get a http client from the pool and request for the content range
var client = httpPool.Get();
var request = new HttpRequestMessage { RequestUri = new Uri(url) };
request.Headers.Range = new RangeHeaderValue(piece.Item1, piece.Item2);
//Request headers so we dont cache the file into memory
if (client != null)
{
var message = await client.SendAsync(request,HttpCompletionOption.ResponseHeadersRead,cancellationToken).ConfigureAwait(false);
if (message.IsSuccessStatusCode)
{
//Get the content stream from the message request
using (var streamToRead = await message.Content.ReadAsStreamAsync(cancellationToken).ConfigureAwait(false))
{
//Create a memory mapped stream to the mmf with the piece offset and size equal to the response size
using (var streams = mmf.CreateViewStream(piece.Item1,message.Content.Headers.ContentLength!.Value,MemoryMappedFileAccess.Write))
{
//Copy from the content stream to the mmf stream
var buffer = new byte[bufferSize];
int offset, bytesRead;
// Until we've read everything
do
{
offset = 0;
// Until the buffer is very nearly full or there's nothing left to read
do
{
bytesRead = await streamToRead.ReadAsync(buffer.AsMemory(offset, bufferSize - offset),cancellationToken);
offset += bytesRead;
} while (bytesRead != 0 && offset < bufferSize);
// Empty the buffer
if (offset != 0)
{
await streams.WriteAsync(buffer.AsMemory(0, offset),cancellationToken);
}
} while (bytesRead != 0);
streams.Flush();
streams.Close();
}
streamToRead.Close();
}
}
message.Content.Dispose();
message.Dispose();
}
request.Dispose();
httpPool.Return(client);
});
I don't know how much it is going to help, but I tried to do something. How well does it work?
I also did some refactoring, so here are some notes:
Do not call .Close() or .Dispose() manually if you already have a using block or a using statement. All it does is add noise to your code and confuse anyone reading it. In fact, almost never call .Close() or .Dispose() manually at all.
Do you realize client would never be returned to the pool if any exception occurred in the method? You need to do these things in a finally block or by using an IDisposable struct which returns client to the pool in it's Dispose() implementation. (also, request would not be disposed in the method if any exception occurred, add using)
Whenever you can, prefer if statements that return early rather than ones that wrap the entire rest of the method. The latter is hard to read and maintain.
You are not really benefiting from Parallel as 99% of the method is asynchronously waiting for IO. Just use Task.WhenAll() instead.
I got rid of the custom buffering/copying and just called the CopyToAsync() method on message.Content which accepts a Stream. It should help the performance, probably. I reckon it has to be better optimized than the simplest possible buffer thingee.
Code:
await Task.WhenAll(pieces.Select(p => DownloadToMemoryMappedFile(p)));
// change the piece type from dynamic to what you need
async Task DownloadToMemoryMappedFile(dynamic piece, CancellationToken cancellationToken = default)
{
//Get a http client from the pool and request for the content range
var client = httpPool.Get();
try
{
using var request = new HttpRequestMessage { RequestUri = new Uri(url) };
//Request headers so we dont cache the file into memory
request.Headers.Range = new RangeHeaderValue(piece.Item1, piece.Item2);
if (client is null)
return;
using var message = await client.SendAsync(request, HttpCompletionOption.ResponseHeadersRead, cancellationToken).ConfigureAwait(false);
if (!message.IsSuccessStatusCode)
return;
//Create a memory mapped stream to the mmf with the piece offset and size equal to the response size
using var streams = mmf.CreateViewStream(piece.Item1, message.Content.Headers.ContentLength!.Value, MemoryMappedFileAccess.Write);
await message.Content.CopyToAsync(streams).ConfigureAwait(false);
}
finally
{
httpPool.Return(client);
}
}
I'm working on porting functionality from an example Windows Forms App to a Xamarin.Forms UWP app where it should write to & read from a bluetooth device on a COM port. I have it working fine most of the time, but intermittently the UWP app will get itself into a state where any call to dataReader.LoadAsync will trigger the exception:
Exception thrown at 0x74AF1A62 (KernelBase.dll) in MyApp.UWP.exe: WinRT originate error - 0x800710DD : 'The operation identifier is not valid.'.
Exception thrown: 'System.Runtime.InteropServices.COMException' in MyApp.UWP.exe
WinRT information: The operation identifier is not valid.
Restarting the app or Visual Studio does not help, the issue persists.
The last time it happened it did not appear to impact my dataWriter writing to the device, only the subsequent read.
All of the code is in the UWP project.
private DataReader _dataReader;
private DataWriter _dataWriter;
private SerialDevice _currentSerialDevice;
private async Task ReadAsync(SerialDevice serialDevice)
{
const uint ReadBufferLength = 1024;
if (_dataReader == null)
{
_dataReader = new DataReader(_currentSerialDevice.InputStream) { InputStreamOptions = InputStreamOptions.Partial };
}
uint bytesRead = await _dataReader.LoadAsync(ReadBufferLength); // <- exception here
if (bytesRead > 0)
{
var vals = new byte[bytesRead];
_dataReader.ReadBytes(vals);
DoStuffWithBytes(vals);
}
}
The serial device is chosen from a list in the application.
// Get serial devices
DeviceInformationCollection serialDeviceCollection = await DeviceInformation.FindAllAsync(SerialDevice.GetDeviceSelector());
// Load serial device from user choosing a device from serialDeviceCollection
public async void ConnectToSerialDevice(DeviceInformation device)
{
_currentSerialDevice = await SerialDevice.FromIdAsync(device.Id);
_currentSerialDevice.BaudRate = 115200;
_currentSerialDevice.Parity = SerialParity.None;
_currentSerialDevice.DataBits = 8;
_currentSerialDevice.StopBits = SerialStopBitCount.One;
_currentSerialDevice.Handshake = SerialHandshake.RequestToSend;
}
Code for writing to the device, which works even when it gets in the odd state:
private async Task WriteToDevice(byte[] outBuffer)
{
if (_currentSerialDevice != null)
{
if (_dataWriter == null)
{
_dataWriter = new DataWriter(_currentSerialDevice.OutputStream);
}
_dataWriter.WriteBytes(outBuffer);
await _dataWriter.StoreAsync();
}
}
I've tried things like flushing the data writer, recreating the datawriter & datareaders each time, but I get the same error nonetheless and cannot read anything from the device. In normal operation I am able successfully read the bytes I'm expecting (even when there are no bytes to be read, it "reads" 0 bytes) and can output this result with no exception.
The curious thing about it all is that not only does the original Windows Forms app work fine (with the same bluetooth device) even after it gets in this state, but just opening the port and reading from the device (in the old app) actually fixes the issue in the UWP app for a time, allowing me to read from the device again.
This may be related to asynchronous methods. You can try this:
var task = await _dataReader.LoadAsync(ReadBufferLength);
task.AsTask().Wait();
uint bytesRead = task.GetResults();
For asynchronous methods (such as DataReader.LoadAsync), events occur on the UI thread and can only be triggered once, and can only continue to be triggered after the previous asynchronous method is completed. Your question may be related to this.
In the end it turns out that the cause of the problem was the LoadAsync method hanging while waiting to fill the entire buffer (1024 bytes) despite the InputStreamOptions being set to Partial. The exception I was getting was somewhat unrelated and was to do with the asynchronous method not working properly (the method was being called again when the first task had not completed).
The fix was a combination of adding a ReadTimeout to the SerialDevice:
_currentSerialDevice.ReadTimeout = TimeSpan.FromMilliseconds(500);
and also wrapping the LoadAsync task itself in a timed cancellation token:
using (var cts = new CancellationTokenSource(500))
{
var task = _dataReader.LoadAsync(ReadBufferLength);
var readTask = task.AsTask(cts.Token);
uint bytesRead = await readTask;
}
This allowed the LoadAsync method to complete both when the device had less than 1024 bytes to consume (handled by the SerialDevice.ReadTimeout) and also when the device had 0 bytes to consume (handled by the CancellationToken).
I'm still not sure why running the win forms app fixed the issue for a time, possibly it was setting the ReadTimeout (while my UWP app was not) and this was persisting on the serial port in some way.
I have a small UWP app which uses a StreamSocket. The socket is accessed via using the socket.InputStream.AsStreamForRead() method.
This works fine for nearly all sizes of incoming data (10 bytes to 6,000 bytes). But when using the overload with a buffer size the socket hangs when more data is received. So 6000 bytes are no longer received if the buffer is set to 4096. Even when reading the data in chunks of 10 bytes it does not work. The method ReadAsync hangs forever.
I am not sure if this is a bug. I would expect that I can still receive the data. If not I need to know the default size or behavior of that buffer.
Example code:
StreamSocket socket = InitSomewhere();
var readStream = socket.InputStream.AsStreamForRead(500);
var buffer = new byte[100]
readStream.ReadAsync(buffer, 0, 100) // Hangs here if received > 500!
Does anyone have an idea?
Best regards, Christan
Firstly, I can not reproduce this issue in my side using the official StreamSocket sample.
On the other hand, you can try to use the DataReader class to read the data as the above sample.
private async void OnConnection(
StreamSocketListener sender,
StreamSocketListenerConnectionReceivedEventArgs args)
{
DataReader reader = new DataReader(args.Socket.InputStream);
try
{
while (true)
{
// Read first 4 bytes (length of the subsequent string).
uint sizeFieldCount = await reader.LoadAsync(sizeof(uint));
if (sizeFieldCount != sizeof(uint))
{
// The underlying socket was closed before we were able to read the whole data.
return;
}
// Read the string.
uint stringLength = reader.ReadUInt32();
uint actualStringLength = await reader.LoadAsync(stringLength);
if (stringLength != actualStringLength)
{
// The underlying socket was closed before we were able to read the whole data.
return;
}
// Display the string on the screen. The event is invoked on a non-UI thread, so we need to marshal
// the text back to the UI thread.
NotifyUserFromAsyncThread(
String.Format("Received data: \"{0}\"", reader.ReadString(actualStringLength)),
NotifyType.StatusMessage);
}
}
I am trying to use the SerialPort class in .net.
I've opted to keep my service async, so I am using the async-methods on SerialPort.BaseStream.
In my async method, I write a byte[] to the serial port, then start reading until I haven't received any more data in n milliseconds, and return that result.
The problem is, however, that I seem to miss the first byte in all replies other than the very first reply after opening the serial port.
If I close the port after every response (Read), and open it again before doing a new request (Write), the first byte is not missing. This, however, often results in a "Access to the port 'COM4' is denied." exception, if I try to open the port too soon after closing. It also seems very unnecessary to open/close for every write/read.
This is basically what my method looks like:
private async Task<byte[]> SendRequestAsync(byte[] request)
{
// Write the request
await _serialPort.BaseStream.WriteAsync(request, 0, request.Length);
var buffer = new byte[BUFFER_SIZE];
bool receiveComplete = false;
var bytesRead = 0;
// Read from the serial port
do
{
var responseTask = _serialPort.BaseStream.ReadAsync(buffer, bytesRead, BUFFER_SIZE - bytesRead);
if (await Task.WhenAny(responseTask, Task.Delay(300)) == responseTask)
{
bytesRead += responseTask.Result;
}
else
receiveComplete = true;
} while (!receiveComplete);
var response = new byte[bytesRead];
Array.Copy(buffer, 0, response, 0, bytesRead);
return response;
}
Is there anything obviously wrong in the way I am doing this? Is there a smarter way to achieve the same asynchronously?
Just because you're not observing the last ReadAsync() doesn't mean it gets canceled, it's still running, which apparently manifests by it reading the first byte of the following message.
What you should do is to cancel the last ReadAsync() by using a CancellationToken. Note that there is a possible race between the timeout and the read, but I'm assuming that if the timeout elapsed, it's not possible for the read to complete without another write.
The code would look like this:
var cts = new CancellationTokenSource();
do
{
var responseTask = _serialPort.BaseStream.ReadAsync(
buffer, bytesRead, BUFFER_SIZE - bytesRead, cts.Token);
if (await Task.WhenAny(responseTask, Task.Delay(300)) == responseTask)
{
bytesRead += responseTask.Result;
}
else
{
cts.Cancel();
receiveComplete = true;
}
} while (!receiveComplete);
Note that both the cause and the solution are my guesses, it's certainly possible that I'm wrong about one or both of them.
I have a line of code, that:
bool stop = await Task<bool>.Factory.StartNew(Listen, (TcpClient) client);
And the corresponding task:
public static async Task<bool> Listen(object state)
{
TcpClient client = (TcpClient) state;
NetworkStream connectionStream = client.GetStream();
IPEndPoint endPoint = client.Client.RemoteEndPoint as IPEndPoint;
byte[] buffer = new byte[4096];
Encoding encoding = Encoding.UTF8;
Random randomizer = null;
// Are we still listening?
bool listening = true;
// Stop the server afterwards?
bool stop = false;
while (listening)
{
int bytesRead = await connectionStream.ReadAsync(buffer, 0, buffer.Length);
if (bytesRead > 0)
{
// Create a new byte array for recieved data and populate
// with data from buffer.
byte[] messageBytes = new byte[bytesRead];
Array.Copy(buffer, messageBytes, messageBytes.Length);
// Generate a message from message bytes.
string message = encoding.GetString(messageBytes);
switch (message)
{
/*
Message handling, where one can set stop to true.
*/
}
}
if (bytesRead == 0 || listening == false)
{
client.Client.Dispose();
break;
}
}
return stop;
}
I have left major parts out of the code, as I feel they do not affect the nature of question.
So yes, when running the application, I get an error:
76: <..>\Program.cs(63,63): Error CS0407: 'System.Threading.Tasks.Task<bool> SOQAsyncQuit.MainClass.Listen(object)' has the wrong return type (CS0407) (SOQAsyncQuit)
Well, I have tried to await Task.Factory.StartNew(...), but then I end up with a different error:
76: <..>\Program.cs(35,35): Error CS0121: The call is ambiguous between the following methods or properties: 'System.Threading.Tasks.TaskFactory.StartNew(System.Action<object>, object)' and 'System.Threading.Tasks.TaskFactory.StartNew<System.Threading.Tasks.Task<bool>>(System.Func<object,System.Threading.Tasks.Task<bool>>, object)' (CS0121) (SOQAsyncQuit)
76: <..>\Program.cs(57,57): Error CS0407: 'System.Threading.Tasks.Task<bool> SOQAsyncQuit.MainClass.Listen(object)' has the wrong return type (CS0407) (SOQAsyncQuit)
76: <..>\Program.cs(29,29): Error CS0029: Cannot implicitly convert type 'void' to 'bool' (CS0029) (SOQAsyncQuit)
I have working void tasks, it's just this that I'm looking forward to transform into a typed result. Since I'm fairly new to C# and .NET in general, I'm out of clues here.
I have also been digging through: http://msdn.microsoft.com/en-us/library/hh524395.aspx, http://msdn.microsoft.com/en-us/library/dd537613(v=vs.110).aspx, some questions on SO, though, neither of them use the Task.Factory.StartNew and I cannot manage to link them together.
What's is the problem here?
Usually with async it would be better to use Task.Run instead of StartNew. You can't if you plan on using a state object. In this case you need to "fix" the StartNew Usage to be:
bool stop = await Task<Task<bool>>.Factory.StartNew(Listen, client).Unwrap();
Listen's return value is of Task<bool> and not bool, and so StartNew's return type would need to be Task<Task<bool>> which you would need to await twice or use Unwrap. Task.Run was built with async in mind and so it does that all for you.